Théo Docquier
email: theo.docquier@loria.fr

Ye-Qiong Song
email: ye-qiong.song@loria.fr

Vincent Chevrier
email: vincent.chevrier@loria.fr

Ludovic Pontnau
email: ludovic.pontnau@scle.fr

Abdelaziz Ahmed-Nacer
email: abdelaziz.ahmed-nacer@scle.fr

Generating substation network simulations from substation configuration description files

The IEC 61850 standard has become the reference standard for substation configuration in smart electric grids, introducing data and service models to achieve interoperability between the network nodes. As the standard is currently based on the switched Ethernet architecture, there is a lot of work on its performance evaluation for guaranteeing realtime constraints. However, there still lacks a link between the substation configuration and its underlying Ethernet performance models (analytic or simulation). For bridging this gap, we propose in this paper a tool, called Simulation Tool for Analysis of substation netwoRkS (STARS) allowing the performance evaluation of any substation configuration through automatic generation of the corresponding simulation model from the Substation Configuration Description (SCD) file. STARS is based on the OMNeT++ simulator allowing the mapping of a real IEC 61850 system configuration to simulation parameters. It also provides a simple network configuration interface. This paper gives an overview of the STARS features through a simple example and points out its future evolution towards co-simulation of substation control algorithms, network performance, and electric grid behaviors.

INTRODUCTION

The need for power utilities in terms of distribution, transport, security and quality of service is growing with the years.

In this context, substations constitute the critical part within a smart grid. Their main goals are to ensure the correct power distribution through the grid, and to react to any abnormal situations. To meet these requirements, substations are composed of multiple Intelligent Electronic Devices (IED), each of them dealing with specific tasks such as the monitoring of voltage/current at different points of the substation or the control of the state of primary equipment (high voltage switches, circuit breakers, transformers...).

Because of the growing number of IEDs within substations, architectures tend to move from traditional hardwired solutions to digital frame based architectures. In such a context, the IEC 61850 standard is specifically defined to meet these challenges. Major contributions of the standard on the interoperability can be summarized in three parts: 1) defining a complete model for electrical components (e.g., power/current/voltage transformer, circuit breaker) using an object-oriented paradigm, 2) allowing the configuration of all equipment belonging to a substation with a language and representation format, and 3) introducing the Ethernet standard for the communication between the equipment and the specification of performance requirement (Table 1). The configuration part introduces the XML based Substation Configuration Language (SCL), described as both a language and a representation format. IEDs and the Substation architecture are fully described respectively by the IED Configuration Description (ICD) and Substation Configuration Description (SCD) files. These two files use the Data Object Model (DOM) defined by the IEC 61850 standard and encode them with an SCL format.

For the communication part, the standard uses switched Ethernet networks as the main basis for the communication architecture. To ensure data communication, three main protocols are introduced: Generic Object Oriented Substation Event (GOOSE) a layer 2 protocol used for fast messages transmission, Sampled Measured Value (SMV) a layer 2 protocol for periodic sample transport on the network and the Manufacturing Message Specification (MMS) a protocol above the TCP/IP layer used for reporting and slow messages transmission.

Contributions of the standard are illustrated Figure 1. The configuration part details the node and communication descriptions of each IED while the network part brings the use of Ethernet standard plus the previously described protocols (MMS, GOOSE & SMV).

However, neither the Ethernet standard nor the specified protocols define mechanisms to guarantee the architecture's determinism or the real-time requirements. Furthermore, the SCD file does not contain any indication about the network architecture's structure i.e., how to interconnect IEDs and devices with each other. This leads to the issue of the network architecture design. Even if the configuration and the communication are already described in the SCD file, the possibilities for the architecture design are multiple. Examples of issues are about the number of switches to use and how to interconnect them, the VLAN configuration or the bandwidth allocation. If the architecture design is not correctly carried out and e.g., the delay of an important message (e.g., a trip order) is too high, it could lead to serious situations, both economically and humanely. Since the communication architecture plays a critical role in substation operations, it must be as reliable as possible. Therefore, it appears a need to have tools that can 1) take into account an SCD file containing IEDs and their properties and 2) build a network architecture with all IEDs and evaluate the performance to guarantee real-time constraints.

At the best of our knowledge, no work has ever considered the configuration part along with the communication part in their works, i.e., taking a real configuration with an SCD file, how to model the network architecture accordingly and how to assess it.

In this paper, we present our approach considering the modeling of the network architecture as well as the mapping of an actual IEC 61850 SCD file to simulation parameters. We finally give an example of simulation and result analysis. The rest of the paper is organized as follows. Section II discusses about the recent works on the substation communication modeling. We describe STARS in Section III and give an overview of its utilization in Section IV. Section V concludes the paper.

RECENT WORKS

In the literature, modeling substation communication is based on two main approaches: analytic and simulation. Analytic modeling: Mathematical models are used to represent the communication architecture. These models are used to determine the worst-case parameters (e.g., delay, backlog) or a statistical approximation for a given scenario. Previous works have been done on the modeling of the MMS protocol [START_REF] Dorsch | Analysing the real-time-capability of wide area communication in smart grids[END_REF] or on the modeling of GOOSE and SMV at the same time with priority policy [START_REF] Huang | A bounded model of the communication delay for system integrity protection schemes[END_REF] both using Network Calculus approach. However, no existing work has taken into account the whole IEC 61850 protocols or existing configuration. Moreover, the pessimism for the worst case scenario always increases drastically as the complexity of the substation grows, making Network Calculus difficult to use for complex cases. Simulation: It consists to choose one network simulator and then develop the model. Recent works have been performed to model and simulate IEC 61850 architecture using the OM-NeT++ simulator. In [START_REF] Juárez | Simulation of iec 61850-based substations under omnet++[END_REF] the three IEC 61850 protocols are implemented while the work made in [START_REF] Héctor León | Simulation models for iec 61850 communication in electrical substations using goose and smv time-critical messages[END_REF] only focuses on GOOSE and SMV. However, neither of them introduce the configuration part of IEC 61850, as their works focus on the development of specific IEC 61850 network communication models.

For the rest of the paper, we focus on the simulation part.

DESCRIPTION OF STARS

Global description

To allow a simple utilisation of a performance evaluation tool, it appears necessary to have two elements: User interface (UI): act as the "input" of the tool. It allows to specify the network architecture, the data model configuration (from the SCD) and simulation parameters; Operation core (OC): act as the "engine" of the tool. It takes the input parameters coming from the UI and runs processes to obtain expected results. The tool can be viewed as a black box system. The only tasks for the user are the configuration of the network architecture plus simulation parameters and the loading of the SCD file corresponding to the substation system configuration the user wants to evaluate.

Figure 2 gives the conceptual view of STARS.

User Interface

STARS UI composition is described by the left part Figure 2. It consists of a sequence of operations the user has to do via the interface before starting the simulation. These operations are as follows: SCD loading: loads the SCD file related to a specific substation; Node description: instantiates each IED of the architecture. Instantiation must be consistent regarding the SCD content as all the IEDs are already described with their configurations; Switches description: instantiates each switch of the architecture; Architecture: describes relations between each node and switch composing the architecture; Scenario description and simulation setting: configures the simulation and scenario parameters. For scenario, the user can configure the number of fault (e.g., thunderbolt on the substation, overload) during the simulation or the period between two faults. For simulation, the user can configure the simulation time and delay thresholds for which the user will be notified if the actual delay exceeds them.

The UI is also responsible for the display of results (e.g., delays, packet loss, buffer utilization) with graphs once the simulation is completed.

Operation core

The STARS OC composition is described by the right part of Figure 2. It is made of three fully automated operations: Parsing: information collected during the configuration part is parsed into files that can be understood by the simulator; Simulating : the result of the parsing operation allows to run the simulation; Computing result: the obtained results are analyzed and processed, then passed to the UI to display the information.

We chose the OMNeT++ simulator for the simulating operation. We used the model developed by [START_REF] Héctor León | Simulation models for iec 61850 communication in electrical substations using goose and smv time-critical messages[END_REF] which is available on the internet for the substation modeling. We added some improvement such as a light version of the MMS protocol, a better mechanism for GOOSE repetition pattern 1 and the possibility to have multiple Application Service Data Units (ASDU 2 ) carried by one SMV frame.

To run a simulation, OMNeT++ needs three different files (according to the user guide manual 3 ): Simulation program: containing the compiled code for modules, simulation kernels and messages. This part contains the core of the model description; NED (Network Description): containing modules (e.g., IEDs, switches, servers ...) and their interactions (e.g., link capacities, propagation delay, frame loss rate...); INI: containing the simulation parameters (e.g., the simulation time) and the parameter descriptions of all modules in the network (e.g., frame sizes, emission periods...).

1 Algorithm used by the GOOSE protocol to ensure the data exchange reliability. It consists of several repetitions of the same message several times. 2 An ASDU can be considered as a group of samples. 3 Available at https://doc.omnetpp.org/omnetpp/manual/ In order to provide the INI and NED files to OMNeT++, we develop two parsers whose role is to extract the required information from the SCD file and generate the NED and INI files. As the model does not change, the simulation program is already compiled and ready to use. As soon as the NED and INI files are generated, the simulation can be run. Once the simulation is completed, the result needs to be displayed. To do so, we developed a third parser taking the result file produced by OMNeT++ and extracting the main values. Once extracted, the results are displayed to the user as illustrated Figure 4. A report containing the result displayed is also automatically created.

STARS'S CAPABILITIES

To illustrate the capabilities of STARS, we consider an SCD file coming from a substation benchmark and describing a real case study. The substation is composed of 17 IEDs. We start by loading the corresponding SCD file into Calc Software. The next step is to define a communication architecture. We consider a network topology with two interconnected switches called "Switch 1" and "Switch 2". All links on Switch 1 are set to 1 Gbps while all links on Switch 2 are set to 100 Mbps. The link between the two switches is set to 1 Gbps. At this stage, we can describe the obtained architecture with Figure 3.

All node behaviors (i.e., protocols used for communication, data to send and the sending periods) are fully described in the INI file where the information is collected from the SCD. In this simple scenario, the parser does not parse SMV from the SCD yet, and future additional work will implement it. GOOSE traffic is emitted by each node (except SUP nodes) to all other nodes. MMS traffic is emitted by each node to one of the declared MMS receivers. In our SCD file, only SUP nodes, ACC 1 and ACC 2 are considered as MMS receivers. GOOSE messages have a higher priority than MMS ones. Before running, we need to configure the scenario and simulation parameters. We choose the following scenario: 10 successive faults appear on the grid with a 1 ms interval, triggering GOOSE and MMS events. For the configuration of simulation parameters, we set the simulation time to 0.2s.

Once the previous step is completed, we can start the run process from Calc Software. Remaining processes (describe subsection 3.3) are handled by the OC part of STARS.

After the simulation is completed, the results can be retrieved as depicted in Fig. 4. For the given SCD and the simulated scenario, we can observe that the maximum delay for GOOSE traffic exceeds the 3 milliseconds limit for trip messages given in Table 1 (all APR nodes). Since APR nodes are set to 100 Mbps, we can speculate that the problem comes from an insufficient bandwidth. If this speculation proves to be true, then we have identified the problem that can be solved to meet the real-time requirement by replacing, for instance, the 100 Mbps link by a 1 Gbps one.

CONCLUSION AND FUTURE WORKS

The main issues addressed in this paper is to design and assess a substation communication architecture while taking into account a real substation configuration. To meet these requirements, STARS brings the following features: Real configuration consideration: the obtained results are based on real SCD files; The main perspective is the improvement of our IEC 61850 model by integrating the new IEEE Time Sensitive Networking (TSN) standard, the latter describing mechanisms and protocols to guarantee determinism for Ethernet-based architecture. Some works have already been done [START_REF] Falk | NeSTiNg: Simulating IEEE time-sensitive networking (TSN) in OMNeT++[END_REF], where a simulation model for TSN standard is proposed. TSN is also investigated by the IEC 61850-90-13 draft about deterministic networking for substations to improve overall performance of the communication network by using network resources efficiently. In addition to TSN study, an investi-gation on scheduling theory to formally describe how to set network parameters for network optimization is planned. Finally, we plan to investigate the co-simulation of our already made communication network model with control and electrical models with the help of the MECSYCO software [START_REF] Camus | Co-simulation of cyber-physical systems using a DEVS wrapping strategy in the MECSYCO middleware[END_REF] to improve results by integrating different fields of expertise to be as close as possible to the reality.

Figure 1 :

 1 Figure 1: IEC 61850 contribution for configuration and communication part.

Figure 2 :

 2 Figure 2: Conceptual view of STARS.

Figure 3 :

 3 Figure 3: Conversion from SCD file to OMNeT++ model.

Figure 4 :

 4 Figure 4: Example of a GUI result at the end of the simulation process Network modeling and investigation: possibility to model a network architecture and assess it in case of non-compliance with real-time requirements. This allows users to detect a potential performance issue and points of failure, and deal with them; Usable by non-expert: spreadsheet interface to design the network architecture, load the SCD, set the simulation parameters and run the simulation with results at the end; Automatic Configuration: the SCD file is automatically parsed into files understandable by OMNeT++ reducing the time of the simulation configuration.The main perspective is the improvement of our IEC 61850 model by integrating the new IEEE Time Sensitive Networking (TSN) standard, the latter describing mechanisms and protocols to guarantee determinism for Ethernet-based architecture. Some works have already been done[START_REF] Falk | NeSTiNg: Simulating IEEE time-sensitive networking (TSN) in OMNeT++[END_REF], where a simulation model for TSN standard is proposed. TSN is also investigated by the IEC 61850-90-13 draft about deterministic networking for substations to improve overall performance of the communication network by using network resources efficiently. In addition to TSN study, an investi-

Table 1 :

 1 Performance requirements for different IEC 61850 applications.


Théo Docquier
email: theo.docquier@loria.fr

Ye-Qiong Song
email: ye-qiong.song@loria.fr

Vincent Chevrier
email: vincent.chevrier@loria.fr

Ludovic Pontnau
email: ludovic.pontnau@scle.fr

Abdelaziz Ahmed-Nacer
email: abdelaziz.ahmed-nacer@scle.fr

Determining a tight worst-case delay of switched Ethernet network in IEC 61850 architectures

Keywords: switched Ethernet, worst-case delay analysis, real-time, Strict-Priority, IEC 61850, smart grid

IEC 61850 has become the reference standard for Substation Automation Systems (SAS) in smart power grids. Switched Ethernet is used for machine to machine communication within SAS. In order to meet stringent realtime constraints, the IEC 61850 application layer protocols can be mapped into different IEEE802.1Q priorities according to their real-time constraints and application criticality. However, the delay evaluation to guarantee realtime requirements can be difficult to perform, especially for lower priority but still real-time constrained traffic. In fact, most existing end-to-end worst-case delay analyses provide upper-bounds, leading to some pessimism and consequently network resource over-provision. In this paper, we present a new method for determining a tight worst-case delay. This method is based on the study of flow characteristics from a given network path. As a flow is interfered by other concurrent flows on its path, their relative offsets with the considered flow greatly impact on its delay. Studying all combinations to find the actual worst-case delay results in high complexity. We show that this complexity can be reduced by only analysing local worst-case delay at each switch in stead of the whole path where the change at each switch would need re-analysing the already analysed switches. An algorithm is also proposed to perform the analysis. An illustrating example shows that our method can reduce the pessimism as it provides the tight worst-case delay instead of the upper-bound of the worst-case delay.

I. INTRODUCTION

Nowadays, power utilities need to provide high quality of energy distribution to companies and customers. It becomes challenging with the progressive introduction of micro-grids, renewable sources and new appliances such as electric vehicles. To guarantee a reliable power distribution, utilities rely on substations to real-timely control and protect the electrical equipment [START_REF] Macdonald | Electric Power Substations Engineering[END_REF], [START_REF] Fang | Smart grid -the new and improved power grid: A survey[END_REF]. A Substation Automation System (SAS) is composed of equipment scattered through the station and dealing with specific tasks (protection, monitoring, control, ...) in a distributed way. These equipment are connected to Intelligent Electronic Devices (IED) which constitute the interface between the physical system and the network. The IEC 61850 standard has been developed in order to guarantee the interoperability of equipment interconnected by networks. It standardizes the use of Ethernet as the main networking technology and includes several application protocols to meet the different SAS application requirements. There are three main application layer protocols: Sampled Measured Value (SMV), Generic Object Oriented Substation Event (GOOSE) and Manufacturing Message Specification (MMS). All IEC 61850 protocols have to meet different time constraints, as specified in [START_REF]Communication networks and systems for power utility automation -part 5: Communication requirements for functions and device models[END_REF]. Therefore, utilities have to meet real-time challenges.

An illustrative example of a Substation associated to its communication network architecture is given in Figure 1. In this example, the power comes from either a power source or another substation (Input power line in Figure 1) and is transmitted to either other substations or directly to customers (Output power line in Figure 1). IEDs are physically connected to electrical equipments like sensors (e.g., the current transformer in Figure 1) or actuators (e.g., the circuit breaker in Figure 1), in order to real-time collecting data from the physical process or to transmit a control order. Information between IEDs is transmitted through the communication network to one or multiple destinations in order to carry out functional tasks. Messages can be transmitted using IEC 61850 protocols as well as other "classic" protocols (e.g., FTP for file transfer, SNMP for network management, NTP/PTP for time synchronization...).

The main issue is to ensure that all messages with realtime requirements will be delivered on time in a switched Ethernet network context, without overprovisioning network resources. One solution is to provide a mapping between messages belonging to IEC 61850 protocols and the Ethernet 802.1Q priority levels. GOOSE messages are mapped with high priority level as they are used for high-Fig. 1. Simple example of a substation and its associate communication network critical operations (applications belonging to TT5-6 classes in Table I). MMS messages are mapped with a lower priority level than GOOSE since they fulfill operations with less stringent requirements (operations belonging to TT0 to TT4 classes in Table I). SMV messages are considered as critical as GOOSE and have traditionally the same priority (operations belonging to TT6 class in Table I). We then have to apply a scheduling policy (e.g., Strict Priority, Weighted Round Robin, ...), based on the related priorities. In IEC 61850 context, Strict Priority is often used as the scheduling policy. Even though the mapping gives more resources to high-priority messages, the endto-end worst-case delay could be difficult to determine, [START_REF]Communication networks and systems for power utility automation -part 5: Communication requirements for functions and device models[END_REF] especially for low-priority messages.

To address this issue, several approaches have been proposed. Simulation is a common method used both for its simplicity, scalability and the possibility to obtain a more realistic view of the results. The worst-case delay is however difficult to reach and it needs theoretically an infinite number of simulations to obtain it (rare event). The worst-case delay can also be obtained by exhaustively analysing all possible combinations of traffic flows in a network, using for instance model checking technique. For evaluating the worst-case end-to-end delay, as all possible network flows with all possible relative offsets between them must be examined, it is in general unscalable facing to the combinatorial explosion problem. Other approaches, such as those based on the network calculus searching for an upper bounded worst-case delay, have also been proposed. Considering maximal arrival curve and minimal service curve can indeed simplify the analysis and ensure a safe upper-bound on delay. Unfortunately, there is a tradeoff between the complexity of the used approach and the pessimism obtained for the worst-case delay bound. This pessimism leads to network overprovisioning, especially with high number of switch hops.

The main contribution of this paper is to propose, for any network's path that a flow goes through, an iterative approach to determine the Worst-Case Delay (WCD) by eliminating all impossible scenarii. As only possible flow offsets are considered, the obtained delay is thus tight by design. Our method is based on the independent local worst-case analysis that considerably reduces the analysis complexity comparing to an exhaustive search of global flow combinations. We first try to find out what is the maximal worst-case delay for a node (end system and switch) and whether it is reachable or not with different flow offsets at their source nodes. If this maximal worstcase delay is not possible, we determine another delay, necessarily lower than the maximal one but being the highest possible. In order to avoid a complex analysis, we work at a flow level instead of a frame level. At the end, we want to obtain a tight end-to-end WCD for all IEC 61850 application protocols, i.e., for protocols using different Ethernet priorities. The determination of the tight WCD allows either to optimize the network architecture or anticipate the architecture scalability.

The rest of this paper is organized as follows: Section II gives more detail about the related work and shows through a motivating example that we can effectively improve the worst-case delay obtained by the Compositional Performance Analysis (CPA). Section III gives elements for the problem formulation. Section IV specifies the method to obtain the tight WCD, as well as the associated iterative algorithm. Section V presents a numerical example illustrating how our proposition can be applied. Finally, Section VI concludes and points out our future work.

II. RELATED WORK AND MOTIVATING EXAMPLE

A. Related works

Different with delay evaluation in general-purpose networks where we do not have stringent deadline (real-time) constraints and queuing theory can be applied to obtain stochastic performance indicators, real-time networking focuses on the worst-case delay evaluation for providing deterministic deadline guarantee to real-time applications. Switched Ethernet and its recent evolution to TSN (time sensitive networking) have attracted many research work.

Searching for the WCD through a switched Ethernet network has been extensively studied over the years. The difficulty of such a task lies in the complexity of the architecture, i.e., the network topology, the number of end-devices scattered through the network, the flow characteristics generated by the source nodes and relative offsets between them, etc... Basically each flow is characterized by the size of its data packet (i.e., Ethernet frame), its generating period (or minimal inter-arrival interval) and its priority level together with its source node, the path it passes through, and its destination node(s). The fundamental issue is to find the worst-case combinations of the flows in order to determine the WCD for each flow of a given priority. In general we consider its generating period as its deadline to be met by the network, that means a frame must be transmitted to its destination before the next one is generated.

The real-time task scheduling theory has been extended e.g., by Tindell and Clark [START_REF] Tindell | Holistic schedulability analysis for distributed hard real-time systems[END_REF] and further by Pop et al. [START_REF] Pop | Schedulability analysis and optimisation for the synthesis of multi-cluster distributed embedded systems[END_REF], taking into account distributed hard-real time systems with static priorities to obtain a worst-case delay. Unfortunately, these approaches become difficult to handle as the network architecture grows in complexity. An exhaustive investigation of all possible flow offset combinations is performed by Charara et al. [START_REF] Charara | Methods for bounding end-to-end delays on an afdx network[END_REF] using the model checking approach. The work is later improved by Adnan et al. [START_REF] Adnan | An improved timed automata approach for computing exact worst-case delays of afdx sporadic flows[END_REF], by reducing the space of possible combinations to analyze, giving a tighter worst-case response-time for more complex architectures. Nevertheless, the resulting combinatorial explosion of such approach, as the network size grows, does not make their use appropriate to industrial size use cases.

To reduce the complexity issue, other approaches have been proposed. Georges et al. [START_REF] Georges | Strict priority versus weighted fair queueing in switched ethernet networks for time critical applications[END_REF] use Network Calculus (NC) to switched Ethernet network with static priorities, giving a method to determine the worst-case delay. A later work by Georg et al. [START_REF] Georg | Performance evaluation of time-critical communication networks for smart grids based on iec 61850[END_REF] uses NC in the IEC 61850 context. However, the intrinsic pessimism of NC does not permit to obtain the tight WCD. In fact, for reducing the analysis complexity, NC considers a maximal arrival curve and minimal service curve, leading to a safe, but over-estimated delay bound. The trajectory Approach with static priorities has been applied with success in [START_REF] Bauer | Applying trajectory approach with static priority queuing for improving the use of available afdx resources[END_REF], with a guaranteed delay bound for AFDX architectures (i.e., switched Etnernet for avionic networks). However, pessimism for the delay bound still remains, its origin being deeper investigated in [START_REF] Li | Analysis of the pessimism of the trajectory approach for upper bounding end-to-end delay of sporadic flows sharing a switched ethernet network[END_REF]. Diemer et al. [START_REF] Diemer | Formal worst-case timing analysis of ethernet topologies with strict-priority and avb switching[END_REF] study an Ethernet with Strict-Priority case using the Compositional Performance Analysis (CPA). This approach uses scheduling analysis at lower granularity level, i.e., on subpart of the system called component, drastically reducing the complexity. However, this complexity reduction leads to pessimism as for the obtained WCD bound.

We developed in a previous work [START_REF] Docquier | Generating substation network simulations from substation configuration description files[END_REF] a tool to automatically generate a network architecture from IEC 61850 network configuration files. This work is based on the one made by Léon et al. [START_REF] León | Simulation models for iec 61850 communication in electrical substations using goose and smv time-critical messages[END_REF], where an IEC 61850 model was proposed. Even though we can run simulations with scenarios that make it easier to get the worst case delay, the latter may actually never be reached since the worstcase is rare event during simulations. To make up for this issue, we propose an analysis to obtain the tight worstcase delay for the GOOSE protocol in [START_REF] Docquier | Iec 61850 over tsn: traffic mapping and delay analysis of goose traffic[END_REF]. However, this work is performed in a Time Sensitive Networking (TSN) context and does not cover other protocols than GOOSE.

B. Motivating example

We take a simple network architecture proposed by Rox and Ernst [START_REF] Rox | Formal timing analysis of full duplex switched based ethernet network architectures[END_REF] as shown in Figure 2, where CPA is used to address the worst-case delay issue. Fig. 2. Architecture example taken from [START_REF] Rox | Formal timing analysis of full duplex switched based ethernet network architectures[END_REF] The flows are called VL (Virtual links according to the terminology of AFDX). Each of them is characterized by its source ES (End System), destination ES, the frame transmission time T tr , the priority and the frame minimal inter-arrival interval BAG (Bandwidth Allocation Gap).

We consider a given set of flows VL as shown in Figure 2, and focus on the WCD of flow VL11 going from ES1 to ES2 through switch A and B. The worst-case delay computed in [START_REF] Rox | Formal timing analysis of full duplex switched based ethernet network architectures[END_REF] is 481µs. However, by counting all possible sources of delay, we obtain 459µs. Sources of delays are described as follows: to reach ES2, we have to count its transmission time three times. This gives: T tr (VL11) × 3 = 121 × 3 = 363µs. Adding up all delays, we have: 52+44+363= 459µs, which is less than the delay of 481µs obtained using the CPA approach given in [START_REF] Rox | Formal timing analysis of full duplex switched based ethernet network architectures[END_REF].

From this simple observation, we can notice that all data with the same destination, or at least competing to access the medium on one node could be a source of extra-delay. As a consequence, we need to formalize this observation in order to determine what is the maximal delay a frame could suffer on one node. Besides, we have to determine if this maximal delay is always reachable or not according to the relative offsets of the incoming frames.

III. PROBLEM MODELLING AND ASSUMPTIONS

We detail the model of the problem in Section III-A followed by the assumptions in Section III-B. Table III summarizes notations used in the paper. Table II and Table III gives respectively abbreviations and notations used in the paper.

A. Problem description

We want to determine the Worst-Case delay (WCD) from the source to the destination for any IEC 61850 protocol message. As a message is encapsulated into an Ethernet frame, we use the term frame instead of message for the rest of the paper. We note as Main Frame (M F ) the frame for which we investigate the WCD. The WCD is determined on a specific path P, on the network depicted as a graph G = (V, E). G is a connected graph and we assume there is only one path from a vertex v i to a vertex v j ∀ v i , v j ∈ V . A vertex v i is either an interconnection node (e.g., switch, router...) or an end-device (e.g., IED, server...). A frame can be stored (queued) in a vertex if it cannot be transmitted immediately. A frame which is not immediately transmitted is considered as blocked (queued). We note the succession of path vertices as v 1 , v 2 , . . . , v n where n is the total number of vertices composing the path. The index i represents the i-th vertex from the first one v 1 (representing the source node) to the last one v n (the destination node).

M F at a vertex v i can be interfered by frames having the same destination as well as frames with other destinations. Since we are only interested in the WCD of the M F , we do not consider other output port than the one that M F passes through.

At v i , M F may suffer from different delays during its transmission: High-Priority blocking delay (T HPi ): delay that a frame has to wait at v i because of the transmission of the higher priority frames (denoted later as HP frames). All frames not having the highest priority may be subject to this delay. Same-Priority blocking delay (T SPi ): delay that a frame has to wait at v i because of the already queued same priority (SP) frames' transmissions. All types of frames may be subject to this delay. This is also called the FIFO queuing delay. Low-Priority blocking delay (T LPi ): delay that a frame has to wait at v i because of the transmission of frames with lower priorities. It describes the non-preemption phenomenon. Frames belonging to all protocols, excepted the lowest priority may be subject to this delay. Transmission delay (T tr ): frame transmission delay. It is given by S C , where C is the link capacity and S the frame size. It includes the propagation delay and the legacy switch latency.

T tr is considered as known and constant and T LPi can be easily computed (non-preemption phenomenon). We only consider two classes of priority: the priority of M F and high priority. For example, if the M F is transmitted with the MMS protocol, all frames transmitted with either SMV or GOOSE belong to the high priority class, with BE only being able to cause one T LPi delay. T SPi and T HPi constitute the main challenge to determine. Using this representation, the W CD for n vertices on P can be given by:

W CD = n-1 i=1 T HPi + n-1 i=1 T SPi + n-1 i=1 T LPi + (n -1)T tr (1)
Where the three sums represent the delay the considered main frame may suffer on each v i , excepted the last one (destination node). For the rest of the paper, we use the notation T HP , T SP and T LP to designate the sum terms. The (n -1) × T tr term describes the n -1 transmission delays to reach the destination from the source. The worstcase T LP delay can be reduced to (n -1) × T LPi , as at most one LP frames can block frames of higher priority at each node (excepted the last one) because of the non-preemption nature of Ethernet frames. Subsequently, following sections focus on determining T HP and T SP .

We formalize the notion of flow, since M F can be blocked by one or multiple frames which may be of the same or high priority. A flow F is defined as a 3-tuple [α;β;γ], with α, β, γ ∈ N. α stands for the sum of SP frames, β the sum of HP frames and γ is the sum of α and β. A flow is said compact if for all frames composing the flow, we have the following relation:

t k = t 1 , if k = 1 t k-1 + T tr , otherwise (2)
where t k is the arrival date of the frame f k on v i . An illustration is given Figure 3. Frames from F c arrive at v i depending on its transmission starting date, called the frame transmission offset in this paper, and the time to arrive from its source to v i . F o is the flow resulting from the competition between F m and q i × F c. It is given by:

F o := qi+1 k=1 α k ; qi+1 k=1 β k ; qi+1 k=1 γ k (3)
In this paper, we assume that F m is indexed as q i + 1.

The organization of frames within F o depends on the order in which the frames get out of v i .

Frames composing the flow could not have the same destination as M F and have to leave the flow on v i . This can be the case, e.g., for unicast traffic only interrupting the flow for one or several vertices on the path. In this paper, we make the assumption that frames leaving the vertex does not affect the compactness of the main flow. This constraint ought be dealt in future works. To take into account the leaving frames, we have to subtract it from F o obtained using Equation 3. This "new" F o (noted F o ) is given by: Once F o is formed, it becomes F m for v i+1 . For considering the worst-case, we assume that M F is always the last frame of F m at each vertex. By the way, as soon as M F is queued in a v i , the outgoing F o becomes a compact flow due to the serialization effect of the output port (i.e., simultaneously arrived frames are transmitted at the output port one by one, only separated by the Ethernet Inter-Frame Gap). We note Γ i the set containing all F c for v i . A summary illustration of the above flow definitions is given in Figure 4. As a conclusion, a path is composed of n vertices where one F m and q i × F c compete to access the medium (i.e., same output port link), the result giving F o. F m on v i is determined by F o on v i-1 or by the number of frames coming out the source node if v i = v 1 . A concurrent flow is determined by aggregating all possible data frame which may constitute it, as illustrated Figure 5. The precise composition of one F c depends on the scenario. On each vertex, F m is disturbed by q i × F c resulting in extra T HP or/and T SP delays for M F .

F o := [α o -f αout ; β o -f βout ; γ o -f γout ] (4)

B. Assumptions and preliminary remarks

• Our approach is a per-flow and per-path analysis method (see Section III-A), meaning it can be applied independently of the network topology. Of course, our approach can be used for all paths in the network, if the WCD for the whole architecture is needed; • There is no constraint on the frame transmission offset setting. This means that we can freely determine the offset at source node of each frame belonging to a concurrent flow in order to maximize delays; • All frames from all end-devices disturb the main flow only once (i.e., no duplication until M F reaches its destination); • All frames have the same size;

• Frames leaving F m does not impact the compactness of F m; • All interconnection nodes (Ethernet switches) use a

Store & Forward policy, with strict priority and a FIFO scheduling within each priority on the output port; • All link capacities are set to constant data rate C.

IV. METHODOLOGY

We present a step-by-step approach to determine T HP and T SP . This term is determined for a frame with a priority that is not the highest. For the sake of readability, proofs of equations provided in this section are put in Appendix.

The methodology is to compute T HP and T SP on each vertex, using its flow characteristics (i.e., α, β and γ values). The computation is based upon the local analysis, described in Section IV-B. Local analysis is repeated for each vertex of the path. Once all T HP and T SP are determined, we sum them up to obtain the T HP + T SP term from Equation 1 and finally determine the WCD.

Section IV-C, gives details about the condition that enables us to iteratively determine T HP and T SP terms. Section IV-D proposes an algorithm to automatically compute the T HP and T SP term.

Before starting, we detail the formation of the first F m, stemming from the source node v 1 .

A. Formation of the first F m

As Figures 4 and5 suggest, F m comes to v 2 (the first interconnection node in Figure 5) from the source node v 1 . Because IEDs can transmit multiple frames due to multiple running IEC 61850 applications, we can have multiple outgoing frames from the same source. The formation of F m in v 1 is as follows: all frames are considered as originating from IEC 61850 applications, thus inducing a contention for the access to the network interface card. This contention is equivalent to have M F regarded as F m and other frames regarded as F c. T HP + T SP in this situation is the time to transmit all frames disturbing M F . The resulting F o becomes F m for the following vertex, i.e., v 2 .

B. Local analysis

The Local analysis is composed of two steps: 1 Determine the Theoretical Local Worst-Case Delay (TLWCD, Definition 1); 2 Check if the T LW CD is possible. 1) Determine the TLWCD: Definition 1: The theoretical local worst-case delay (TLWCD) for the main flow F m on a vertex v i is the T SPi + T HPi delay caused by all frames of all F c. The T LW CD is defined by:

T LW CD = T tr qi j=1 γ j (5)
The T LW CD cannot always be reached, depending on flows α, β and γ values on v i The next step is to determine if this delay is reachable or not.

2) Check if the T LW CD is reachable: The T LW CD is reachable if and only if the following condition is met:

γ qi+1 ≥ max(β j ) j∈[1;qi] (6)
The proof for Inequation 6 is given in Appendix, Section A. For the rest of the paper, we call the condition given by Inequation 6 the T LW CD condition.

If the T LW CD condition is met, the worst-case delay for the vertex v i is found and equal to the T LW CD.

If the T LW CD condition is not met, we have to determine a new worst-case delay necessarily lower than the TLWCD. This new worst-case delay is called the Possible Local Worst-case Delay (P LW CD, Definition 2).

Definition 2: The Possible Local Worst-Case Delay (P LW CD) for the main flow F m on a vertex v i is the T SPi + T HPi delay caused by all F c giving their α, β or γ values. The P LW CD is defined by:

P LW CD = T LW CD -T tr ((max(β j ) j∈[1;qi] -γ qi+1 ) (7)
The proof of Equation 7 is given in Appendix, Section B. Once the P LW CD is determined, we add it to the WCD obtained from v i-1 , giving the WCD for v i . F m and F c are aggregated to form F o, the latter becoming F m for v i+1 , becoming a compact flow (see section III-A) at the same time. The operation is repeated on the following vertices.

In the following Section, we explain how we can guarantee that the local analysis can be performed on each vertex.

C. Extension to the global path

The previous section highlights the methodology to obtain T HP + T SP . This is done by adding up all T HPi + T SPi , which are equal to T LW CD or P LW CD. T LW CD and P LW CD are independently computed for each vertex v i , using the per-node local analysis. This implies that the methodology can be used on v i regardless of the consequence to obtain the worst-case delay on previous vertices. However, in order to compute the T LW CD and the P LW CD at v i , frames from different F c have to reach v i at a specific date in order for Equation 7and Equation 5to be used. Constraints on frame transmission offsets thus appear for each frames on the network.

The methodology proposed in the previous section does not need to know the frame transmission offset settings to be applied. However, we have to prove that such settings exist in order to be able to apply the local analysis on each vertex of the path. This is provided by Theorem 1.

Theorem 1: The T HP + T SP term can always be determined by adding all T HPi + T SPi determined by the local analysis if there is no constraint about the frame transmission offset at source node for all frames on the network.

Proof: We first demonstrate the proof on one vertex, then extend it to the overall path.

1) One vertex: We use Figure 6 as an illustration for the one vertex proof, with details explained thereafter.

Let v i ∈ P be composed of one F m and one F c and tc 1 the date when the first frame f 1 from F c reaches v i . Let assume that we are not constrained on the frame transmission offset. Let assume that a given scenario to get the worst-case delay requires that f 1 reaches v i at a date denoted by ts. We first have:

tc 1 = ts
If we assume that f 1 needs a duration T 1 to reach v i from its source node v 1 , we can deduce the transmission offset for f 1 :

of f set 1 = tc 1 -T 1 Fig. 6. Frame transmission offset for each frames to obtain a compact flow

In order to apply Equation 5 or 7, respectively to compute T LW CD or P LW CD, a compact flow is needed, as demonstrated in their respective proofs. If we define tc 2 , tc 3 . . . tc k the date when frames f 2 , f 3 . . . f k reach v i and using the definition of compact flow given by Equation 2, we have:

tc k = tc 1 , if k = 1 tc k-1 + T tr , otherwise
We can deduce each frame transmission offset for each frame from F c by:

of f set k = tc k -T k
where T k is the time for the frame f k to reach v i from its source node.

At the end, we only have to know the date ts, which is equal to tc 1 . All tc k values are deduced from tc 1 using a recurrence relation. ts depends on the requirement to achieve the worst-case delay on v i .

The previous reasoning is independent of other F c. This is due to the fact that all other frames from other F c do not reach v i by the same output port than frames from F c as there exist only one path between two vertices (definition of G section III-A).

2) Overall path: If there is no constraint on the frame transmission offset, we need two information on each vertex of the path:

• F m characteristics, i.e., its α, β, γ values;

• the date when the first frame from F m reaches the vertex. From the first information, we determine whether T LW CD or P LW CD is used to compute T HPi and T SPi on v i . ts for v i is determined depending the case. Once ts is determined for v i , it can be used as reference for all incoming flows competing on v i .

We can then schedule tc 1 for each F c to obtain the selected delay with the help of the second information.

D. Algorithm

The methodology described in Section IV-B is formalized with Algorithm 1. sumV ertex = getSumFlowForVertex(Γ i , F m, i)

Algorithm 1 Tight worst-case delay computation

Input: n, F m, Γ 1 , Γ 2 , . . . Γ n Output: W CD Initialisation: W CD = 0 1: for i = 1 to n do 2: if (isTLWCDReachable(Γ i , F m) == true) then 3: WCD = WCD + getTLWCD(Γ i , F m) 4:
8:
F o = substractFramesLeavingVertex(sumV ertex, i)

F m = F o 10: end for 11: return W CD Additional remarks:

• The variable W CD represents the T HP + T SP .

• We sum all T HP + T SP at each step of the algorithm (line 3 or 5). • Functions getSumFlowForVertex(), substract-FramesLeavingVertex(), isTLWCDReachable(), getTLWCD(), getPLWCD(), use Equations 3, 4, 5, 6, and 7, respectively.

• The function substractFramesLeavingVertex() subtracts all frames from F o not having the same destination as MF.

V. APPLICATION CASE

This section propose a concrete example (architecture given in Figure 7) to illustrate our methodology. To set these ideas on the example, we can imagine an architecture similar to the one shown in Figure 1. For this application case, we consider frames with a constant size S and a constant link capacity C for the whole network with a transmission time of T tr = S C = 1. The final result gives T SP + T HP delay which must be added to T LP and T tr . To be in the worst-case, we assume that low priority blocking resulting in T LP systematically occurs at each vertex v i excepted the last one (destination node). T tr occurs on each edge (i.e., network links) traversed by the frame. As an IEC 61850 architecture, we consider M F being transmitted by a low-priority protocol, e.g., MMS. Therefore, HP frames belongs either to SMV or GOOSE 7 and LP frames belongs to best-efforts protocols. In order to simplify the analysis, we consider that all frames of all F c have the same destination as M F . We consider that the periodicity of all flow is equal to the WCD.

Results are summarized in Table IV. v 1 is composed of MF and 7 concurrent frames generated by IEC 61850 applications. In the worst-case, M F has to wait the transmission of all concurrent frames before being itself transmitted. As M F has been disturbed by 7 frames, the WCD at v 1 is set to 7. F o is subsequently formed by the aggregation of all frames from v 1 .

On v 2 , F m can be disturbed by all F c frames, according to T LW CD condition. The WCD is incremented by T LW CD, giving a W CD of 23 at v 2 .

v 3 becomes the first vertex where T LW CD condition is not met making it impossible to obtain the TLWCD. We then compute the P LW CD using Equation 7 and add it to the current W CD. The result becomes 457. v 4 is in the same situation as v 1 , i.e., the condition to obtain T LW CD is met. The WCD is incremented by the T LW CD obtained on v 4 , giving 517 as the result.

W CD = 11465
WCD gives a tight representation of what the worst-case delay for an MMS frame is in case of the architecture given figure 7. As long as the periodicity of all F c in the network is greater than or equal the WCD, the latter can be guaranteed. This information could be used by the IEC 61850 engineer, e.g., to configure the IEC 61850 architecture accordingly.

Note that operations used to obtain the WCD are boiled down to simple operations at each node (i.e., comparison, sum and maximum operations), reducing thus the complexity and allowing the scalability of our analysis method.

VI. CONCLUSION, FUTURE WORKS

In this paper, we proposed a new approach to determine a tight WCD for switched Ethernet running strict-priority policy, with a focus on supporting IEC 61850 protocols requiring different real-time constraints. This approach is based on local worst-case delay analysis and an iterative algorithm, working with flows modeled as a 3-tuple object representing the quantity of same-priority, high priority and total number of frames.

Through this modelling, we deduced several properties used to determine a tight end-to-end WCD, depending on the number of frames of different priorities which compose a flow. All the analysis remains upon the possibility to schedule all transmission offsets at source nodes for each frame of the network, allowing us to gives the worst-case scenarii in which the WCD is encountered. As we do not focus on the determination of these offsets, we simply consider them as possible, only searching for the WCD. Finally, the determination of the WCD is scalable, as we only need to perform basic operations such as comparison or sum on each path vertex. The complexity depends on the number of vertices and the number of F c for each vertex. An algorithm is also provided implementing the methodology. Although this work is motivated by the IEC 61850 application context, the proposed approach can be used in other use cases using Ethernet with strict-priority supported by IEEE802.1Q.

Our future work will focus on extending our method to take into account the multiple frame sizes. We also aim to integrate this work into our previous analysis made in [START_REF] Docquier | Iec 61850 over tsn: traffic mapping and delay analysis of goose traffic[END_REF] in order to obtain a complete analysis of the WCD in a IEC 61850 context with an integrated TSN technology.

APPENDIX

A. Proof of Inequation 6

Determination of T SPi : Let us assume that all incoming flows on v i are compact and that the first frame from each flow reaches v i at the same time. Knowing that F m competes with q i F c, we can deduce that each SP frame from F m is disturbed by q i frames for each T tr . Moreover, if we make the assumption that SP frames are first transmitted by all F c and γ qi+1 ≥ max(β j ) j∈ [1;qi] , then all frames of F m are disturbed by all SP frames from the largest F c. All SP frames from all F c disturb F m. Consequently, T SPi is given by:

T SPi = T tr qi j=1 β j If γ qi+1 < maxβ j j∈[1;qi]
, some frames coming from F c with the highest β value will not disturb M F from F m as the latter will be either already transmitted or stored in v i .

Determination of T HPi : Assume that the first HP frames from all F c start to reach v i once the last SP frame from all F c are stored. If all HP frames from all F c form a compact flow, all HP frames block SP frames from F m that are not yet transmitted. T HPi is given by: , leading to T LW CD condition. 7We determine both T HPi and T SPi to obtain WCD. Determination of T SPi : We search to maximize the blocking time caused by SP frames from F c to F m on v i . The blocking time caused by SP frames to other SP frames can be of two kinds:

T HPi = T tr qi j=1 α j

B. Proof of Equation

• direct blocking: SP frames from one or multiple F c reach v i at the same time than a SP frame from F m and is the last served; • indirect blocking: SP frames from one or multiple F c are already queued on v i , blocking in turn frames from F m because of a FIFO scheduling policy for SP frames. HP frames from F m cannot be blocked by SP frame. However, HP frames always block all SP frames from other F c, which leads to an indirect blocking delay for the following SP frames from F m. Thus, the blocking time is the same regardless the priority of the the frame from F m.

If γ qi+1 < max(β j )

j∈ [1;qi] (Inequation 6 not met), it is impossible for F m frames to be disturbed by all frames from all F c.

To maximize T SP we can consider the following situation. Firstly, we assume that the last frame from F m reaches v i at the same date, denoted by t last , than the last frame from the concurrent flow having the highest β value. This leads to the situation that all frames from F m are disturbed by SP frames from the F c with the highest β value, causing direct blocking. We note by t f irst the date when the first frame from F m reaches v i . We deduce the following relation:

t last = t f irst + γ qi+1 × T tr
Secondly, we assume that all F c start to transmit their SP frames at a same date t < t f irst . This leads to accumulate SP frames from all F c while frames from F m have not yet reached v i , causing indirect blocking. We note by: ∆ = t f irst -t the duration between the arrival of all first frames from F c and the arrival of the first frame from F m. All frames transmitted during ∆ therefore do not disturb F m.

Knowing that the number of frames transmitted between t last -t is given by: max(β j ) j∈[1;qi] = t last -t T tr and that the number of frames transmitted between t last -t f irst is given by:

γ qi+1 = t last -t f irst T tr
we can deduce that:

∆ = t f

Fig. 3 .

 3 Fig. 3. Illustration of a compact flow

  where α o , β o , γ o are the values of F o formed using Equation 3, and f αout , f βout , f γout frames leaving v i and not going to v i+1 . For the rest of the paper, we use the notation F o instead of F o to designate the outgoing flow after removing leaving frames.

Fig. 4 .

 4 Fig. 4. n vertices with their main flow, concurrent flows and outgoing flow

Fig. 5 .

 5 Fig. 5. Flow formation and aggregation

else 5 :

 5 WCD = WCD + getPLWCD(Γ i , F m)

Fig.

  Fig. 7. Architecture under study

v 5 and v 6 1 i=1T

 61 lead to the same situation, namely T LW CD is not possible, thus computing the P LW CD and add it to the W CD. The final result gives 11455, which represents T HP + T SP for the given path. Using Equation 1, we can compute the WCD by adding up T LP and T tr :W CD = T HP + T SP + n-LP + (n -1)T tr W CD = 11455 + T tr (n -1) + (n -1)T tr W CD = 11455 + 1(6 -1) + 1(6 -1)

Finally, M F

 M has to wait T SPi + T HPi : + β j ) = T tr qi j=1 γ j which corresponds to the definition of T LW CD given by Equation5. This waiting time is only possible if γ qi+1 ≥ max(β j ) j∈[1;qi]

  irst -t ∆ = (-T tr × γ qi+1 + t last ) -(-T tr × max(β j ) j∈[1;qi] + t last ) ∆ = T tr (max(β j ) j∈[1;qi] -γ qi+1 )Apart from frames transmitted during ∆, all SP frames from all F c disturb frames from F m. T SPi is thus given by:T SPi = T tr ( qi j=1 β j ) -∆ T SPi = T tr ( qi j=1 β j -(max(β j ) j∈[1;qi] -γ qi+1 ))where qi j=1 β j is the sum of all SP frames from all F c. Determination of T HPi : Let us assume that the first HP frames from all F c start to reach v i once the last SP frame from all F c are stored. If all HP frames from all F c form a compact flow, all HP frames block SP frames from F m that are not yet transmitted. T HPi is given by:T HPi = T tr qi j=1 α jFrom our previous analysis, we can sum T HPi and T SPi : j + β j ) we have:P LW CD = T LW CD -T tr ((max(β j ) j∈[1;qi] -γ qi+1 )which corresponds to the definition of P LW CD given by Equation7. Note that if:γ qi+1 = max(β j )j∈[1;qi] we have:P LW CD = T LW CD which is consistent with Inequation 6.

TABLE I PERFORMANCE

 I REQUIREMENTS FOR DIFFERENT IEC 61850 APPLICATIONS

  [START_REF] Adnan | An improved timed automata approach for computing exact worst-case delays of afdx sporadic flows[END_REF]. Architecture under study +1 ≥ max β j (j ∈ [1;q i ]) (Inequation 6)

						Vertices (v i )
			v1	v2	v3	v4	v5	v6
				Incoming flows
	F m		[0; 1; 1] (M F )	[5; 3; 8]	[14; 10; 24]	[214; 320; 534]	[224; 370; 594]	[874; 1520; 2394]
	q i		0	2	4	1	2	3
				Local analysis results
	T LW CD i (Equation 5)	7	16	510	60	1800	11350
	γ q i +1		-	8	24	534	594	2394
	max(β j ) (j ∈ [1;q i ])	-	4	100	50	700	4500
	γ q i -	true	false	true	false	false
	P LW CD i (Equation 7)	-	-	434	-	1694	9244
				Outgoing flow and WCD
	W CD i		7	23	457	517	2211	11455
	F o (F m +	q i j=1 F cj , Equation 3)	[5; 3; 8]	[14; 10; 24]	[214; 320; 534] [224; 370; 594] [874; 1520; 2394] [1724; 12020; 13744]

TABLE IV RESULTS

 IV WITH ALGORITHM 1 WITH THE EXAMPLE ARCHITECTURE GIVEN FIGURE