Fully-Deterministic Execution of IEC-61499 Models for ... - MDPI

aerospace Article

Fully-Deterministic Execution of IEC-61499 Models for Distributed Avionics Applications Carlos C. Insaurralde School of Science and Engineering, Teesside University, Middlesbrough TS1 3BX, UK; [email protected]; Tel.: +44-1642-38-4331 Received: 31 October 2017; Accepted: 22 January 2018; Published: 3 February 2018

Abstract: The development of time-critical Distributed Avionics Applications (DAAs) pushes beyond the limit of existing modeling methodologies to design dependable systems. Aerospace and industrial automation entail high-integrity applications where execution time is essential for dependability. This tempts us to use modeling technologies from one domain in another. The challenge is to demonstrate that they can be effectively used across domains whilst assuring temporally dependable applications. This paper shows that an IEC61499-modeled DAA can satisfy temporal dependability requirements as to end-to-end flow latency when it is properly scheduled and realized in a fully deterministic avionics platform that entails Integrated Modular Avionics (IMA) computation along with Time-Triggered Protocol (TTP) communication. Outcomes from the execution design of an IEC61499-based DAA model for an IMA-TTP platform are used to check runtime correctness through DAA control stability. IEC 61499 is a modeling standard for industrial automation, and it is meant to facilitate distribution and reconfiguration of applications. The DAA case study is a Distributed Fluid Control System (DFCS) for the Airbus-A380 fuel system. Latency analysis results from timing metrics as well as closed-loop control simulation results are presented. Experimental outcomes suggest that an IEC61499-based DFCS model can achieve desired runtime latency for temporal dependability when executed in an IMA-TTP platform. Concluding remarks and future research direction are also discussed. Keywords: Integrated Modular Avionics; Time-Triggered Protocol; IEC 61499; runtime correctness; time-critical avionics applications

1. Introduction Avionics systems have undergone transformations since first aircraft have flown. They have gone through changes due to technological innovations to provide airborne capabilities (mostly required for aircraft management). The updates include typical avionics equipment for communication, navigation, and surveillance systems and technologies for vehicle systems such as flight control systems, fuel systems, and hydraulic systems. This continuous improvement and modernization brings along an inexorable evolution of the avionics architecture. The evolutionary process of architectural avionics approaches goes from former centralized and analogue solutions to latter decentralized and digital ones [1]. The latter involve networked computers and entail distributed, federated, and integrated avionics architectures. They are more lightweight (reduction of wiring) and efficient (reduction of power consumption) than former solutions whilst providing higher performance (although they are more complex and expensive). They also facilitate the realization (implementation and integration) of Distributed Avionics Applications (DAAs), mainly favoring systems dependability due to the fault tolerance provided by the distribution of functionalities. Integrated Modular Avionics (IMA) is the latest generation of avionics architectures fostered by the aviation industry [1]. The ultimate purpose of IMA is the standardization of the onboard

Aerospace 2018, 5, 15; doi:10.3390/aerospace5010015

www.mdpi.com/journal/aerospace

Aerospace 2018, 5, 15

2 of 30

processing computers, so all the avionics software applications use and share the same electronic hardware platform (applications are developed for specific partitions or virtual processors). This makes scalability and reusability for further system expansions and assurance of safety-critical requirements along with Real-Time (RT) performance for certification easy [2]. Additionally, the computing and networking nature of the IMA technology allows for deployment of DAAs. DAAs make good use of the IMA architecture by deploying their functionalities along networked computers and interconnecting them to build the entire DAA. DAAs usually involve embedded RT paradigms for control and guidance. Computation and communication time is critical in DAAs since failing to meet operation deadlines may have catastrophic consequences. This manifests the tight relation between timing and dependability (temporal correctness in addition to logical correctness). Some examples of DAAs are autopilot systems, the Traffic Alert and Collision Avoidance System (TCAS), flight management systems, and the fuel measurement and management systems. The development of time-critical DAAs pushes to the limit and beyond existing engineering methodologies and tools (particularly, modeling languages for distributed deployment and execution of modelled DAAs) to design dependable avionics systems [3]. The same challenging situations can be found in other domains such as in industrial automation, where distributed RT applications also face temporal dependability requirements. Aerospace and automation have a long history of working separately. On the one hand, this makes sense, since the technological culture to approach systems development (e.g., control software engineering practice) differs from one domain to another. Software applications are typically co-developed along with hardware platforms in aerospace, whilst they are usually developed after the factory machinery is installed in the shop-floor (in industrial automation). On the other hand, both domains entail high-integrity applications where execution time is essential for dependability. This similarity tempts us to use modeling technologies from aerospace in industrial automation and vice versa. The challenge is to demonstrate that such technologies can be effectively used across domains whilst assuring development of temporally dependable applications. The IEC-61499 standard [4] for industrial automation is an attractive candidate to model DAAs. It is a graphical modeling language that encapsulates functionality in Function Blocks (FBs) to be deployed in networked devices for low-level control (usually RT control). FBs are building blocks (hardware-like software components) for the representation of distributed control systems (a network of FBs). Their interface entails events and data as the inputs and outputs for the FBs. Events trigger internal FB algorithms that process external/internal data. The standard is meant to enable reusability and portability of wrapped functionalities (the FBs) and distribution and reconfiguration of applications. The research discussed in this paper involves the execution design of a DAA. The DAA model is based on the IEC-61499 standard. The research objective is to demonstrate simply that the IEC61499-modeled DAA can satisfy temporal dependability requirements as to end-to-end flow latency when it is realized in a deterministic avionics platform. The standard is fairly questioned for the lack of notation for execution time (determinism). However, the execution of the DAA model is studied when it is deployed and executed in a fully time-driven platform: time-partitioned computation and time-triggered communication. The former is provided by the IMA architecture, and the latter is provided by the Time-Triggered Protocol (TTP) [5]. The combination of these two technologies allows for fully-synchronous execution of the DAA since it provides temporally deterministic DAA behavior to guarantee predictive timing performance. The event-driven DAA FBs are synchronously executed (time-driven and enabled by events) in the IMA partitions, and FB events are transmitted over a TTP-based network. Execution design of an IEC61499-based DAA model running in an IMA-TTP platform is carried out to provide insights on the control stability of the DAA by checking effectiveness of the design in terms of execution time. Thus, closed-loop control simulation results are presented. This paper presents an application example of the IEC-61499 standard for a DAA. The case study is a distributed fluid control system for the Airbus-A380 fuel system. Dependable fuel management is crucial for safe aircraft operation [6]. One of the key design aspects for the above system to reach safety


3 of 30

and ultimately dependability is to have temporally-deterministic performance. Hence, reliable timing for computation of the fuel levels as well as communication between sensors/effectors and controllers is vital to achieve time-related determinism and guarantee low end-to-end latency for runtime correctness [7]. This latency depends on the scheduling of tasks in the control computer (computation) and packets in the TTP network (communication). Therefore, timing metrics are applied to the DAA scheduling to realize about the above latency (including worst/best-case latencies). In fact, latency analysis results from end-to-end latency metrics are presented. The paper is organized as follows. Section 2 presents the research background by recapping technological aspects about the IMA architecture, the TTP paradigm, and the IEC-61499 standard and existing initiatives to integrate them with each other. Section 3 describes basic but relevant details of the fuel system of Airbus A380-800 considered by the case study. Section 4 shows details (four representation levels) of the IEC-61499 modeling of the DAA for the FMMS platform. Section 5 discusses the execution design and latency analysis approaches along with results from timing metrics (based on the DAA scheduling). Section 6 presents the modeling and simulation of the DAA control loop and a study the impact of the end-to-end latency (due to the DAA execution) on the stability of such a loop. Section 7 discusses the experimental results obtained and compares the IEC-61499 standard with other modeling approaches for DAAs. Section 8 presents conclusions and future research directions. 2. Technological Background This section reviews three relevant technologies for the platform and application used in this paper and existing initiatives to integrate them with each other. 2.1. Integrated Modular Avionics IMA is a computation platform that has been developed as a standard for avionics applications to facilitate the integration of hardware and software systems. Its architecture is meant to combine the benefits from a centralized computer organization with a decentralized one. IMA has processing units (modules) logically divided into virtual processors (aka partitions). These modules can exchange data with shared inputs/outputs modules as well as other processing modules. Module partitions can exchange data with other partitions (from a same module or a different one). From a hardware viewpoint, IMA is a collection of physical modules located in a rack or cabinet. This concept can be seen in other domains such as industrial automation (backplane-based modular controllers). From a software viewpoint, IMA provides execution independence for software applications by means of isolated and dedicated partitions from a RT Operating System (RTOS) [8] that complies with the ARINC-653 standard [9] for aviation. Time partitioning and RT execution of IMA partitions guarantee meeting synchronization constraints in time-critical avionics applications. Time RTOS partitioning provides a deterministic scheduling mechanism to assure partitions are predictively executed and switched from a partition context to another. Minor frame is the time slot for execution of each RTOS partition, and major frame is the time slot for execution of a set of RTOS partitions. Figure 1 shows the concept of the IMA architecture along with some examples of connections between modules/partitions.


4 of 30

Aerospace 2018, 4, x FOR PEER REVIEW

4 of 30

Aerospace 2018, 4, x FOR PEER REVIEW Cabinet 1

Processing Module 1 Cabinet 1 PartitionProcessing Partition Module 1Partition A B N Partition A

Partition B

4 of 30

Cabinet k

… … …

Partition N

Sensors and Effectors

Processing Module m Cabinet k

Sensors and

PartitionProcessing PartitionModule mPartition A B N

I/OEffectors Module 1

……..…...

I/O Module 1

Partition A

……..…...

…

Partition B

Partition N

Avionics Data Communication Network (ADCN) Avionics Data Communication Network (ADCN)

Partition A

Partition B

…………..…...

Partition N

I/O Module 2

Partition Partition Partition A Processing B Module 2 N

I/OEffectors Module 2

I/O Module n

…………..…...

Sensors and

Sensors and

I/OEffectors Module n Sensors and

Sensors and Effectors

Cabinet 2 Processing Module 2

Cabinet 3 Effectors

Figure 1. Space/time-partitioned architecture in Integrated Modular Avionics (IMA). Cabinet 2 Cabinet 3 Figure 1. Space/time-partitioned architecture in Integrated Modular Avionics (IMA). Figure 1. Space/time-partitioned architecture in Integrated Modular Avionics (IMA). 2.2. Time-Triggered Protocol 2.2. Time-Triggered Protocol The TTP [5] Protocol is a communication platform that has been mainly developed to provide 2.2. Time-Triggered The TTP [5](along is a communication platform that has been developed provide determinism with a fault-tolerant mechanism) whenmainly transmitting data to packets. It determinism is fast and The TTP [5] is a communication platform that has been mainly developed to providethe (along with a fault-tolerant mechanism) when transmitting data packets. It is fast and helps helps predict the moment (not an exact time but a time slot) in which data are sent out to the predict network determinism (along with a fault-tolerant mechanism) when transmitting data packets. It is fast and moment (not an exact time but a time slot) in which data are sent out to the network and are received and are received by the network’s nodes. Its off-line scheduling mechanism and fault-tolerant helps predict the moment (not an exact time but a time slot) in which data are sent out to the network bycapability the network’s Itsaoff-line scheduling mechanism and fault-tolerant capability make the TTP makenodes. the TTP great candidate for time-critical DAAs. The TTP communication platform and are received by the network’s off-line scheduling platform mechanism and fault-tolerant complies with the AS6003 [10] fornodes. aerospace systems. a great candidate forSAE time-critical DAAs. TheIts TTP communication complies with the SAE capability partitioning make the TTP athe great for DAAs. Multiple The TTP communication insystems. TTPcandidate is dictated bytime-critical the Time-Division Access (TDMA) platform strategy. AS6003Time [10] for aerospace complies with the SAE AS6003 [10] for aerospace systems. TTP nodes are allowed send only time (one at aMultiple time) in Access each TDMA round (set Time partitioning into the TTPout is messages dictated by theone Time-Division (TDMA) strategy. Time partitioning in the TTP is dictated bythere the Time-Division Multiple Access (TDMA) strategy. of nodes node slots). TDMAto rounds are periodic and no chance outgoing in of TTP are allowed send out messages only oneistime (one atofacollision time) in of each TDMAmessages round (set TTPTDMA nodes round are allowed tothe send outseparation messagesbetween only onesenders. time (one at a time) in each TDMA round (set the due to time node slots). TDMA rounds are periodic and there is no chance of collision of outgoing messages in the of node slots).shows TDMAthe rounds areof periodic and there is no chanceprovided of collision outgoing Figure concept time-driven communication byof the TTP. messages in TDMA round 2due to the time separation between senders. the TDMA round due to the time separation between senders. Figure 2 shows providedby bythe theTTP. TTP. Figure 2 showsthe theconcept conceptofoftime-driven time-driven communication communication provided Node 2

Node 4

Node 6

Node 8

Node 10

Node 12

………....…...

Node n

Node 2

Node 4

Node 6

Node 8

Node 10

Node 12

………....…...

Node n

Communication Network Communication Network Node 1

Node 3

Node 5

Node 7

Node 9

Node 1

Node 3

Node 5

Node 7 Node 9 TTP off-line scheduling

Node 11

Node 13

………....…...

Node m

Node 11

Node 13

………....…...

Node m

Cluster cycle

.………………………………….......

TDMA round m1...i

Node 1 slot m1...i

Node 1 slot

m1

Node 2 slot m1

Node 2 slot

m1...k

Node 6 slot m1...k

m1...j

Node 9 slot m1...j

m1

Node 3 slot m1

TTPm1off-line scheduling &2 ma m1 & 4

m1...i

Node 5 slot

Cluster cycle

Node 8 slot

TDMA round

m1...i

m1 & 2

Node 10 slot ma

Node 7 slot m1 & 4

m5

Node m slot m5

m1 & 6

Node 4 slot m1 & 6

m3

Node n slot m3

Figure Time-driven the10 slot Time-Triggered Node2. 9 slot Node 3 slot Nodemessaging 5 slot Node 8 slot inNode Node 7 slot Node m slotProtocol Node 4 slot (TTP). Node n slot

Node 6 slot

Figure2.2.Time-driven Time-driven messaging messaging in Figure in the the Time-Triggered Time-TriggeredProtocol Protocol(TTP). (TTP).

mi+1...r

m2

… ...

.…………………………………....... Node 1 slot Node 2 slot mi+1...r

Node 1 slot

m2

Node 2 slot

… ...


5 of 30

2.3. IEC 61499 Standard Aerospace 2018, 4, x FOR PEER REVIEW

5 of 30

TheIEC IEC 61499 standard [4] has been developed to model distributed control applications in 2.3. 61499 Standard industrial automation [11]. The standard is able to model the above applications by encapsulating and The IEC 61499 standard [4] has been developed to model distributed control applications in interconnecting functionalities wrapped in hardware-like software blocks or Function Blocks (FBs). industrial automation [11]. The standard is able to model the above applications by encapsulating The combination of encapsulated functionalities is to build up the representation of the IEC-61499 and interconnecting functionalities wrapped in hardware-like software blocks or Function Blocks application under development. IEC 61499 follows the software paradigmofofthe component (FBs). The combination of encapsulated functionalities is to buildengineering up the representation IECorientation whilst keeping of IEC object-oriented IEC-61499 paradigm applications 61499 application under properties development. 61499 followsarchitectures. the software engineering of are deployed in resources from whilst devices. component orientation keeping properties of object-oriented architectures. IEC-61499 Figure 3 shows the application-device-resource-FB encapsulation method of the IEC-61499 applications are deployed in resources from devices. 3 shows the top-left application-device-resource-FB encapsulation method of theinIEC-61499 standard.Figure Clockwise from to bottom-left, applications can be deployed one or more standard. Clockwise from On top-left bottom-left, can be deployed in one through or more devices devices (application view). thetotop, devices applications are connected with each other a network, (application view). On the top, devices are connected with each other through a network, and linked and linked with the process under control (bottom). Devices (e.g., control computers or instruments) with the process under control (bottom). Devices (e.g., control computers or instruments) can have can have one or more resources that are able to contain deployed FBs. FBs are for computation and one or more resources that are able to contain deployed FBs. FBs are for computation and communication. Computation FBs are classified as basic FBs, composite FBs, and sub-application FBs. communication. Computation FBs are classified as basic FBs, composite FBs, and sub-application FBs. Communication FBsFBs areare generally categorized andresponder responderFBs. FBs. Communication generally categorizedas asrequester requester and Application view

Device view

Inter-device communication links (network)

Communication interface Device 2

Device 1

Device k

Application 2

Resource A

Device j Application 3

Resource B

Application 10

Application 4

Application 4

Process (under control)

Process interface

Event inputs

Execution Control Chart

Event outputs

Communication interface

Type identifier

Type identifier

Type identifier

Internal variables

Data inputs

Algorithm 1

Data outputs

Algorithm k

Basic FB

Composite FB

Event

INT

INT0

Event

INT

INT0

Event

Event

REQ

CNF

Event

REQ

CNF

Event

Bool

Q1

Q0

Bool

Q1

Q0

Bool

Any

PARAMS

STATUS

Any

PARAMS

STATUS

Any

Any

SD_1

RD_1

Any

SD_1

RD_1

Any

Any

SD_m

RD_n

Any

SD_m

RD_n

Any

REQUESTER

RESPONDER

Events

Events

Algorithm 2

Sub-application

Resource D

Application 3

Application 1

Application 1

App n

Resource C

Service Interface Function Block (SIFB)

Data

Basic/ Composite Function Block(s)

Data

Service Interface Function Block (SIFB)

Fragment or full distributed application

Process (under control) Execution scheduling of Function block(s)

Function-Block view

Resource view

Figure 3. Encapsulation and hierarchy of IEC-61499 models.

Figure 3. Encapsulation and hierarchy of IEC-61499 models.

2.4. Related Work

2.4. Related Work

The IEC-61499 standard has long been used to develop control applications of Distributed TimeThe IEC-61499 standard has long automation. been used Early to develop controlofapplications Distributed Critical Systems (DTCSs) in industrial considerations the IEC-61499ofstandard for avionics include(DTCSs) DTCSs such as an aircraft fuel management system [12,13].of Athe later discussionstandard on Time-Critical Systems in industrial automation. Early considerations IEC-61499 the use of the above modelling standard fromfuel industrial automation for aerospace has alsodiscussion been for avionics include DTCSs such as an aircraft management system [12,13]. A later presented by the author of this paper [3]. from industrial automation for aerospace has also been on the use of the above modelling standard The research presented in this paper combines three technologies: IMA, TTP, and IEC 61499. presented by the author of this paper [3]. Even though the IMA and TTP technologies are from about two decades ago, there are not many The research presented in this paper combines three technologies: IMA, TTP, and IEC 61499. approaches that integrate them or discussions on their combination. This is in great part because IMA Evencomes though the IMA and TTPFull technologies are from about two decades there are not many along the Avionics Duplex (ADFX) communication platform.ago, However, existing approaches that integrate them or discussions on their combination. This is in great part because IMA approaches include a network performance analysis [14], platform modelling based on Time-comes alongTriggered the Avionics Full Duplex (ADFX) However, existing approaches include Constraint-Based Calculuscommunication (TTCC) [15,16], platform. a scheduling algorithm for distributed IMA

a network performance analysis [14], platform modelling based on Time-Triggered Constraint-Based Calculus (TTCC) [15,16], a scheduling algorithm for distributed IMA based on a network partition


6 of 30

integrating model [17], a cost optimization strategy for iterative integration of IMA and Time-Triggered Ethernet (TTEthernet) multi-critical functions [18], embedded cloud computing for critical systems [19,20], and PhD dissertations about integrated task and message scheduling for time-triggered aerospace systems [21] and mixed-criticality in distributed real-time systems [22]. Publications of research works on the combination of TTP with IEC61499 are few, and they naturally come from industrial automation. An effort has been made to evaluate communication protocols for distributed RT control systems in industrial automation developed by the IEC-61499 standard [23]. This effort evaluates industrial networks such the Controller Area Network (CAN) and its variations, including Time-Triggered CAN (an implementation of the TTP). Also, a formal model for distributed IEC61499-based systems has been proposed. Such a research contribution aims at providing a locally synchronous execution platform (no network involved) for FBs and recommends TTPs for globally synchronous execution [24] in order to reach fully synchronicity (local and global time partitioning). Another approach proposes a time-stamped event-based solution for execution semantics of IEC-61499 FBs of industrial cyber-physical systems considers time-triggered and event-triggered mechanism for the execution platform [25]. The semantic approach aims to comply with deterministic RT requirements of the above systems. The situation in term of publications is even worse for the combination of IMA with IEC 61499. There have been very few publications on this subject so far. Whilst the idea of using the IEC 61499 standard in aerospace avionics is not novel [12,13], as discussed at the beginning of this subsection, the first published intent to combine the IMA platform with the deployment of IEC-61499 applications comes from recent years [3]. The combining proposal makes a point on the demand of innovative engineering methods and tools to analyze/notate requirements for DTCSs. Modeling languages play a key role in the design process of DTCSs, and the IEC 61499 standard is an attractive modeling methodology for DTCSs. The proposal also presents a discussion on issues related the IEC 61499 standard as a potential tool for aerospace systems. The scheduling problem in time-partitioned avionics systems is gaining interest in the aerospace community. Following this direction, different approaches have been proposed to deal with the scheduling of time-driven tasks and messages. A scheduling algorithm (synchronized highest level first) along with two rescheduling and backtracking procedures (release time deferment and backtracking and priority promotion) have been proposed [26]. The algorithm is meant to schedule periodic applications (task graphs) that involve periodic and aperiodic tasks and messages from safety-critical time-triggered avionics systems. Other scheduling approach makes use of model checking techniques to compute schedules with RT requirements for optimal solutions and reduction of end-to-end latency [21]. 3. Case Study This section presents basic but relevant details of the fuel system of Airbus A380-800 [6] considered by the case study. 3.1. Aircraft Fuel Rig The Airbus A380-800 fuel rig entails mechanical and electromechanical components such as tanks, pipes, valves, pumps, and sensors. The fuel storage is located in the wings by means of several fuel tanks arranged one after the other and interconnected to make fuel transfers possible. The rig main operations are refueling/defueling, engine supply, fuel transfer, and fuel jettison. It also provides fuel to the Auxiliary Power Unit (APU) and Hydraulic System Cooling (HSC). The rig functionality is very sophisticated and critical for a safe aircraft operation. Thus, dependability is particularly essential for temporal actions of valves and pumps to carry out the above operations. The fuel rig system has eleven fuel tanks along with three vent tanks and two surge tanks. They are configured in three isolated sets of tanks located in (1) the left wing, (2) the right wing, and (3) the horizontal stabilizer. Each of the wings has five fuel tanks, a surge tank, and a vent tank. The five tanks are an Outer Tank (OT) with a capacity of about 10,448 L, an Outer Engine Feed


7 of 30

Aerospace 2018,a4,capacity x FOR PEER REVIEW 7 of 30 36,453 L, Tank (OEFT) with of about 27,634 L, a Mid Tank (MT) with a capacity of about an Inner Transfer Tankof(ITT) about L, of and an36,453 InnerL,Engine Feed Tank (IEFT) with a capacity aboutwith 27,634aL,capacity a Mid Tankof(MT) with46,144 a capacity about an Inner Transfer with a capacity of about 29,374ofL.about The46,144 horizontal stabilizer hasFeed a trim tank. Tank (ITT) with a capacity L, and an Inner Engine Tanktank (IEFT)and withaa vent/surge capacity of about 29,374 L. The horizontal stabilizer trimwing tank and tank. Figure 4 shows Figure 4 shows the configuration of tanks for has thealeft anda vent/surge the specific part of the fuelthe tank system configuration of tanks for the left wing and the specific part of the fuel tank system that is considered that is considered in the case study.

in the case study.

Left inner engine (Engine 2)

Left outer engine (Engine 1)

PE Inner Engine Feed Tank (IEFT)

Center wing box

PT

Vent Tank (VT)

Outer Tank (OT)

Surge Tank (ST)

Outer Engine Feed Tank (OEFT)

Mid Tank (MT)

PM

Inner Transfer Tank (ITT)

Figure 4. Fuel tank system for the Airbus A380-800 left wing (adapted view from [6]).

Figure 4. Fuel tank system for the Airbus A380-800 left wing (adapted view from [6]). The case study scenario considers fuel transfer and supply operations in the left wing. There are

The case study scenario considers fuel and supply operations the left supply wing. There are two fuel transfers: one from the MT to the transfer ITT and the other from the ITT to IEFT.in The engine operation is to provide left inner engine 2 with fuel during fuel burn sequencing (aircraft operation). two fuel transfers: one from the MT to the ITT and the other from the ITT to IEFT. The engine supply The fuel is steadily transferred from the MT to the ITT as well as from the ITT to IEFT during normal operation is to provide left inner engine 2 with fuel during fuel burn sequencing (aircraft operation). aircraft operation. The IEFT must be as full as possible at all times to avoid starvation and guarantee The fuel isbest steadily feedingtransferred to engine 2. from the MT to the ITT as well as from the ITT to IEFT during normal aircraft operation. The IEFT must be as full as possible at all times to avoid starvation and guarantee 3.2.to Fuel Measurement best feeding engine 2. and Management Platform The Airbus A380-800 fuel rig has a Fuel Measurement and Management System (FMMS). The FMMS has an and electronic hardware Platform platform that is based on IMA computation and Avionics Full 3.2. Fuel Measurement Management DupleX (AFDX) communication. The case study considers a platform based on IMA, although the

The Airbus A380-800 fuel has Processor a Fuel Measurement and (CPIOMs) Management System communication between IMArig Central Input/Output Modules is assumed to be (FMMS). carried means of the TTP. The arrangement of the is CPIOMs in pairs: CPIOMand for Avionics The FMMS has out an by electronic hardware platform that basedis on IMAa command computation fuel(AFDX) management and a monitoring CPIOM fuel measurement. Full DupleX communication. The casefor study considers a platform based on IMA, although the The CPIOMs are interconnected with each other, the Fuel Quantity Data Concentrators (FQDCs), communication between IMA Central Processor Input/Output Modules (CPIOMs) is assumed to be and the Integrated Refuel Panel (IRP). The FQDCs are data acquisition units to compute fuel quantity carried outdata byand means of the TTP. arrangement of5). the CPIOMs is in pairs: connected a command CPIOM for get feedback from The effector signals (Figure The FQDCs are originally to the CPIOM via ARINC 429 and are not an IMA module (CPIOM). The avionics configuration of the above fuel management and a monitoring CPIOM for fuel measurement. FMMS is twin redundancy. However, the case studythe considers no redundancy that the FQDC (FQDCs), The CPIOMs are for interconnected with each other, Fuel Quantity Dataand Concentrators is included in the CPIOM and connected via TTP (instead of ARINC 429). and the Integrated Refuel Panel (IRP). The FQDCs are data acquisition units to compute fuel quantity Effectors and sensors connected with each other through embedded computers (IMA) and a data and get feedback from signals (Figure FQDCs are originally connected to the network (TTP) close theeffector control loop. This link defines5). theThe end-to-end latency that is relevant to the fuel control 429 application discussed this paper. CPIOM via ARINC and are not aninIMA module (CPIOM). The avionics configuration of the above FMMS is twin for redundancy. However, the case study considers no redundancy and that the FQDC is included in the CPIOM and connected via TTP (instead of ARINC 429). Effectors and sensors connected with each other through embedded computers (IMA) and a network (TTP) close the control loop. This link defines the end-to-end latency that is relevant to the fuel control application discussed in this paper.


8 of 30


8 of 30


8 of 30

Figure 5. Fuel measurement and management platform (adapted view from [6]).

Figure 5. Fuel measurement and management platform (adapted view from [6]). 4. Distributed Fuel Control Application Figure 5. Fuel measurement and management platform (adapted view from [6]).

4. Distributed Fuel Control Application This section shows details of the IEC-61499 modeling of the DAA for the FMMS platform, including fourControl representation levels as discussedmodeling in Section 2.3. 4. Distributed Fuel Application This sectiontheshows details of the IEC-61499 of the DAA for the FMMS platform, including the four representation levels as discussed in Section 2.3. This sectionApplication shows details 4.1. IEC-61499 View of the IEC-61499 modeling of the DAA for the FMMS platform,

including the four representation levels as discussed in Section 2.3.

TheApplication FMMS platform executes a control software application deployed across the controlling and 4.1. IEC-61499 View monitoring CPIOMs. This DAA is modelled by the IEC-61499 standard. It was modelled by means of

4.1. IEC-61499 Application View

ThetheFMMS platform executes a Kit control software across the controlling and Function Block Development (FBDK) [27], andapplication experimentaldeployed results are available in an earlier TheCPIOMs. FMMS executes a control software application deployed the controlling and publication [3].platform The IEC61499-compliant DAA model is dividedstandard. into the following monitoring This DAA is modelled by the IEC-61499 Itacross was sub-applications: modelled by means of controlBlock command, fuel cockpit panel, fuel level display, and data sensingresults concentration. It isby deployed monitoring CPIOMs. This DAAKit is modelled by theand IEC-61499 standard. It was are modelled means the Function Development (FBDK) [27], experimental available in anof earlier three different IEC-61499 devices each CPIOM is modelled): aresults CPIOM-Control, (2) ainCPIOMtheinFunction Block Development Kit (as (FBDK) and experimental available an earlier publication [3]. The IEC61499-compliant DAA[27], model is divided(1)into the are following sub-applications: Monitor, and (3) aIEC61499-compliant CPIOM-Acquisition, DAA i.e., the Fuel Quantity Data (FQDC). Figure 6 publication [3]. The model is divided intoConcentrator the following sub-applications: control shows command, fuel cockpit panel, fuel level display, and data FMMS sensing concentration. It is how the fuel FMMS DAApanel, is distributed the CPIOMs. The fullconcentration. DAA and its FBs control command, cockpit fuel levelover display, and data sensing It is deployed deployed in three differentservice IEC-61499 devices each CPIOM is modelled): (1) a CPIOM-Control, (without the interface FBs) are shown in(as Appendix A. in three different IEC-61499 devices (as each CPIOM is modelled): (1) a CPIOM-Control, (2) a CPIOM(2) a CPIOM-Monitor, and (3) a CPIOM-Acquisition, i.e., the Fuel Quantity Data Concentrator (FQDC). Monitor, and (3) a CPIOM-Acquisition, i.e., the Fuel QuantityCPIOM-Monitoring Data Concentrator (FQDC). Figure 6 CPIOM-Sensing CPIOM-Control Figure 6 shows how the FMMS DAA is distributed over the CPIOMs. The full FMMS DAA and its FBs shows how the FMMS DAA is distributed over the CPIOMs. The full FMMS DAA and its FBs (without the interface service FBs) are A. (without the interface service FBs) areshown shownin in Appendix Appendix A. Dataconcentration CPIOM-Sensing sub-application

Dataconcentration sub-application

CPIOMSensing

Control-command sub-application CPIOM-Control

Fuel-cockpit-panel sub-application

Fuel-level-display CPIOM-Monitoring sub-application

Control-command sub-application

TTP Fuel-cockpit-panel sub-application CPIOMControl

Fuel-level-display sub-application

CPIOMMonitoring

Fuel Measurement and Management System TTPApplication (FQDC)

IMA

Distributed Avionics Application X

CPIOMCPIOMDistributed Control Y Sensing Avionics Application

CPIOMMonitoring

Fuel Measurement and Management System Application (FQDC) Fuel sensors

Other CPIOMs

Fuel effectors (valves & pumps)

Other CPIOMs

IMA

Distributed Avionics Application X Other aircraft systems Fuel tank systems

Distributed Avionics Application Y

Fuel sensors

Fuel effectors (valves & pumps)

Other aircraft systems Fuel tank systems

Figure 6. Distributed fuel control application.


9 of 30

Figure 6. Distributed fuel control application.


9 of 30

The IEC61499-compliant FMMS devices host different pieces of the DAA, i.e., sub-applications The IEC61499-compliant FMMS host different pieces of the DAA, i.e.,fuel-cockpit-panel sub-applications deployed in device’s resources. The devices control-command sub-application and the deployed in device’s resources. The control-command sub-application and the fuel-cockpit-panel sub-application are deployed in CPIOM-Control. The fuel-level-display sub-application is deployed sub-application are deployed CPIOM-Control. The fuel-level-display deployed in in the CPIOM-Monitor. Theinsensing-concentration sub-application sub-application is deployed inisthe CPIOMthe CPIOM-Monitor. The sensing-concentration sub-application is deployed in the CPIOM-Acquisition. Acquisition. Sub-applications FBsFBs thatthat provide specific functions to thetowhole DAA Sub-applications are arebuilt builtofofinterconnected interconnected provide specific functions the whole functionality. FBs from resources (partitions) or devices (CPIOMs) communicate with with each DAA functionality. FBs different from different resources (partitions) or devices (CPIOMs) communicate other by means of a of publisher-subscriber mechanism (service FBs). each other by means a publisher-subscriber mechanism (service FBs).FBs FBswithin withinthe thesame same resource are directly interconnected (no SFBs are required). The FBs from each sub-application are presented in Appendix B. The case is on This entails the following functionalities: pilot interface, casestudy studyfocus focus is the on ITT the control. ITT control. This entails the following functionalities: pilot ITT sensing, pump control, fuel gauging. Thus, functionalities (FBs) related the ITT interface, ITTmid sensing, mid pumpand control, and fuel gauging. Thus, functionalities (FBs)to related to are the considered for simplification of the case study. this However, does not invalidate demonstration of ITT are considered for simplification of theHowever, case study. this doesthe not invalidate the fully-deterministic execution for FBs. Two scenarios are investigated to analyze the DAA performance. demonstration of fully-deterministic execution for FBs. Two scenarios are investigated to analyze the DAA sub-applications aresub-applications deployed in onlyare one resourceinper device in scenario There is similar performance. DAA deployed only one resource per1.device in ascenario deployment situation for the DAA sub-applications (insub-applications scenario 2) except the control-command 1. There is a similar deployment situation for the DAA (infor scenario 2) except for the and fuel-cockpit-panel sub-applications, which are deployed in different resources (partitions) from control-command and fuel-cockpit-panel sub-applications, which are deployed in different resources CPIOM-Control (device). Hence, the control-command is distributed in two different (partitions) from CPIOM-Control (device). Hence, sub-application the control-command sub-application is resources (within the CPIOM-Control device), and the fuel-cockpit-panel sub-application is deployed distributed in two different resources (within the CPIOM-Control device), and the fuel-cockpit-panel in a third resource of the CPIOM-Control deviceofinthe scenario 2. sub-application is deployed in a third resource CPIOM-Control device in scenario 2. 4.2. IEC-61499 Device Device View View 4.2. IEC-61499 Figure thethe CPIOM-Sensing device along along with itswith resources and how the Figure 77shows shows CPIOM-Sensing device its resources andsub-applications how the subare deployed in resources. Each IMA partition entails two resources. The data-concentration applications are deployed in resources. Each IMA partition entails two resources. The datasub-application is only deployed in resource I.A in forresource scenarioI.A 1 and CPIOM-Sensing device can also concentration sub-application is only deployed for 2. scenario 1 and 2. CPIOM-Sensing deploy other DAAs such as the distributed application W and Y. device can also deploy other DAAs such as control the distributed control application W and Y. TTP

IMA Partition I Resource I.A Dataconcentration

Resource I.B

IMA Partition II Resource II.A

Resource II.B

IMA Partition III Resource III.A

Resource III.B

Distributed control sub-application of application W

sub-application

Distributed control sub-application of application Y

Fuel tank system interface

Figure 7. Central Processor Input/Output Module (CPIOM)-Sensing device. Figure 7. Central Processor Input/Output Module (CPIOM)-Sensing device.

Figure 88 shows showsthe theCPIOM-Control CPIOM-Controldevice devicealong along with resources and how sub-applications Figure with itsits resources and how thethe sub-applications are are deployed in resources. Each IMA partition entails two resources. The fuel-cockpit-panel subdeployed in resources. Each IMA partition entails two resources. The fuel-cockpit-panel sub-application application is only deployed resource I.A, and the sub-application control-command sub-application is only is only deployed in resource I.A,in and the control-command is only deployed in resource deployed in resource I.B of partition I in scenario 1. The fuel-cockpit-panel sub-application is only I.B of partition I in scenario 1. The fuel-cockpit-panel sub-application is only deployed in resource deployed in resource I.A, and the control-command sub-application is deployed in resource I.B I.A, and the control-command sub-application is deployed in resource I.B (partition I), resource II.B


10 of 30


10 of 30

(partition and resource III.A (partition III)resource in scenario 2. CPIOM-Control can2.also deploy other (partitionII), I), resource II.B (partition II), and III.A (partition III) in device scenario CPIOM-Control DAAs such as the distributed control application X, Y, and Z. device can also deploy other DAAs such as the distributed control application X, Y, and Z. TTP

IMA Partition I Resource I.A

Resource I.B


Resource II.B

Fuel-cockpitpanel s ub-


Resource III.B

Distributed control sub-application of application X

application



Distributed control sub-application of application Z


TTP


Resource I.B


Fuel-cockpitpanel s ubapplication

Resource II.B


Resource III.B

Distributed control sub-application of application X





Figure 8. CPIOM-Control device: device configuration for scenario 1 (top); Device configuration for Figure 8. CPIOM-Control device: device configuration for scenario 1 (top); Device configuration for scenario 2 (bottom). scenario 2 (bottom).

Figure99shows shows CPIOM-Monitoring device its resources andsub-applications how the subFigure thethe CPIOM-Monitoring device along along with itswith resources and how the applications are deployed in resources. Each IMA partition entails two resources. The fuel-levelare deployed in resources. Each IMA partition entails two resources. The fuel-level-display sub-application display sub-application is only deployed in resource I.A (partition I) in scenario 1, and it is deployed is only deployed in resource I.A (partition I) in scenario 1, and it is deployed in resource I.A (partition III) in in resource I.A (partition III) in scenario CPIOM-Sensing deploycontrol other DAAs such scenario 2. CPIOM-Sensing device can also2.deploy other DAAsdevice such ascan thealso distributed application as the distributed control application Y and Z. Y and Z.


11 of 30


11 of 30

TTP


Resource I.B


Resource II.B


Resource III.B





TTP


Resource I.B


Resource II.B


Resource III.B





Figure 9. CPIOM-Monitoring device: device configuration for scenario 1 (top); Device configuration Figure 9. CPIOM-Monitoring device: device configuration for scenario 1 (top); Device configuration for scenario 2 (bottom). for scenario 2 (bottom).

4.3. IEC-61499 Resource View 4.3. IEC-61499 Resource View Table 1 shows the deployment of FBs from the sub-applications for scenario 1, and Table 2 shows Table 1 shows the deployment of FBs from the sub-applications for scenario 1, and Table 2 shows the deployment of FBs from the sub-applications for scenario 2. the deployment of FBs from the sub-applications for scenario 2. Table 1. Allocation of deployed sub-applications (scenario 1). Table 1. Allocation of deployed sub-applications (scenario 1).

Device

Sub-Application

Functionality

Partition

Device

Sub-Application

Functionality

Partition

CPIOM-Sensing

Data-concentration

ITT sensing

I

Transfer pump control

I

CPIOM-Sensing CPIOM-Control

CPIOM-Control

CPIOM-Monitoring CPIOM-Monitoring

Data-concentration

ITT sensing

Mid pump control Control-command Mid pump control Transfer pump control Control-command Fuel-cockpit-panel

Pilot interface

Fuel-cockpit-panel

Pilot interface

Fuel-level-display

Fuel gauging

Fuel-level-display

Fuel gauging

I

Resource

Resource

I.A

I.A

I I

I

I.A

I.A

I.A

I.A

Table 2. Allocation of deployed sub-applications (scenario 2).

Device

Sub-Application

Functionality

CPIOM-Sensing

Data-concentration

ITT sensing

I

I.A

Control-command

Mid pump control Transfer pump control

II III

II.A III.B

Fuel-cockpit-panel

Pilot interface

I

I.A

Fuel-level-display

Fuel gauging

III

III.A

CPIOM-Control CPIOM-Monitoring

Partition Resource


12 of 30

Table 2. Allocation of deployed sub-applications (scenario 2). Device

Sub-Application

Functionality

Partition

Resource

CPIOM-Sensing

Data-concentration

ITT sensing

I

I.A

Control-command

Mid pump control Transfer pump control

II III

II.A III.B

Fuel-cockpit-panel

Pilot interface

I

I.A

Fuel-level-display

Fuel gauging

III

III.A

CPIOM-Control CPIOM-Monitoring


12 of 30

The defines aa distributed distributed fuel fuel control control application application where where parts parts of of it it (DAA (DAA sub-applications) sub-applications) The DAA DAA defines are are distributed distributed across across device device resources resources from from the the FMMS FMMS platform. platform. Architectural Architectural details details and and layout layout of of the DAA sub-applications are shown within each resource as follows. the DAA sub-applications are shown within each resource as follows. Figure 10 shows showsFB FBdetails detailsofofthe the CPIOM-Sensing device resource scenario 1 and 2. Figure 10 CPIOM-Sensing device resource I.A I.A for for scenario 1 and 2. The The configuration of resource I.A is according to Tables 1 and 2, where the data-concentration configuration of resource I.A is according to Tables 1 and 2, where the data-concentration subsub-application is only deployed in Partition for both scenarios. application is only deployed in Partition I forIboth scenarios.

TTP

ILPub

ILAcq

START COLD WARM STOP

INT REQ

SCAN STA RT

E_RESTART

E0

PUB_1

IO_READER #Sensor _ID

E_CYCLE t#1ms

INT0 CNF

INT REQ

INT0 CNF

#IL_Addr

ID

ID SD_1

RD_1

DT

Full data-concentration sub-application

Fuel tank system (under control) Execution scheduling of Function block(s) Figure 10. Reassure I.A from CPIOM-Sensing device for scenario 1 and 2. Figure 10. Reassure I.A from CPIOM-Sensing device for scenario 1 and 2.

Figure 11 CPIOM-Control device resource I.AI.A for for scenario 1 and 2. The Figure 11 shows showsFB FBdetails detailsofofthe the CPIOM-Control device resource scenario 1 and 2. configuration of resource I.A is according to Table 1, where the fuel-cockpit-panel sub-application The configuration of resource I.A is according to Table 1, where the fuel-cockpit-panel sub-application and the thecontrol-command control-command sub-application aredeployed both deployed in IPartition I (scenario 1). The and sub-application are both in Partition (scenario 1). The configuration configuration is according tothe Table 2, where the fuel-cockpit-panel is of resource I.Aof is resource accordingI.A to Table 2, where fuel-cockpit-panel sub-application issub-application only deployed in only deployed in Partition I (scenario 2). Partition I (scenario 2).


13 of 30


13 of 30

TTP FPan INT

ILSub INT

INT0 IND

SPI

Fuel-cockpit-panel and control-command sub-applications

ILSam

REQ

CNF

CNF

SUBL_1

FACEPLATE 100

INT0 IND

IRSam REQ

#IL_Addr

SP

ID

RD_1

SAMPLE_UINT IN

FB_REAL_UNIT

OUT

IN

OUT

MPPIDC

REQ

START

CNF

RENDEZVOUS

COLD WARM STOP

0

EO

EI1 EI1 R

E_RESTART

FB_PIDR True

E_REND

MPQue

REQ

MPPub

INT REQ

CNF

t#250m s t#1s t#0s

XOUT

PUB_1

FB_REAL_UNIT IN

2.5

INT0 CNF

AUTO PV SP XO KP DT TR TD

ID

OUT

SD_1

Fuel tank system (under control) Execution scheduling of Function block(s)

TTP

START

IRPub

FPan

COLD WARM STOP

INT

E_RESTART

INT REQ

INT0 IND

FACEPLATE 100

SPI

INT0 CNF

PUB_1 SP

#IR_Addr

ID SD_1

Full fuel-cockpit-panel sub-application

Fuel tank system (under control) Execution scheduling of Function block(s)

Figure 11. Reassure I.A from CPIOM-Control device: resource configuration for scenario 1 (top); Figure 11. Reassure I.A from CPIOM-Control device: resource configuration for scenario 1 (top); Device configuration for scenario 2 (bottom). Device configuration for scenario 2 (bottom).

Figure 12 12 shows shows FB FB details details of of the the CPIOM-Control CPIOM-Control device device resource resource II.A II.A for for scenario scenario 22 (there (there is is no no Figure deployment of the control-command sub-application in this resource for scenario 1). The deployment of the control-command sub-application in this resource for scenario 1). The configuration configuration II.A according to the Table 2 where the control-command is of resource II.Aofisresource according toisTable 2 where control-command sub-applicationsub-application is only deployed only deployed resourceII). II.A (Partition II). across resource across II.A (Partition


14 of 30

Aerospace 2018, 4, x FOR PEER REVIEW Aerospace 2018, 4, x FOR PEER REVIEW

14 of 30 14 of 30

TTP TTP

IRSub INT

ILSub

IRSub INT0

INT

IND INT0 IND

INT

IRSam REQ

SUBL_1 #IR_Addr #IR_Addr

ID

IRSam

REQ RD_1

ILSam

IND INT0 IND

ILSam

CNF

SUBL_1

CNF

SUBL_1 RD_1

ID

ILSub INT0

INT

SAMPLE_UINT

#IL_Addr

ID

SUBL_1 RD_1

#IL_Addr

ID

RD_1

CNF

REQ

CNF

FB_REAL_UNIT FB_REAL_UNIT IN OUT

INSAMPLE_UINT OUT IN

REQ

OUT

IN

START

Fuel-cockpit-panel Fuel-cockpit-panel and control-command andsub-applications control-command sub-applications MPPI DC

OUT

MPPI DC

RENDEZVOUS

START COLD WARM COLD STOP WARM STOP

0 0

E_RESTART

EI1RENDEZVOUSEO EI1 EO EI1 R EI1 R

E_RESTART

True

E_REND

True

MPPub

MPQue

CNF

REQ

CNF

FB_REAL_UNIT FB_REAL_UNIT IN OUT IN

OUT

INT REQ INT REQ

#MP_Addr

ID

#MP_Addr

SD_1 ID

CNF

REQ

CNF

FB_PIDR

E_REND

MPQue

REQ

REQ

2.5

MPPub INT0 CNF INT0 CNF

PUB_1 PUB_1

t#250m s 2.5 t#1ss t#250m t#0s t#1s t#0s

AUTOFB_PIDRXOUT PV AUTO XOUT SP PV XO SP KP XO DT KP TR DT TD TR TD

SD_1

Fuel tank system (under control) Fuel tank system (under control) Execution scheduling of Function block(s) Execution scheduling of Function block(s) Figure 12. Reassure II.A from CPIOM-Control device: resource configuration for scenario 2. Figure 12. Reassure II.A from CPIOM-Control device: resource configuration for scenario scenario 2. 2.

Figure 13 shows FB details of the CPIOM-Monitoring device resource I.A for scenario 1 and the Figure Figure 13 13 shows shows FB FB details details of of the the CPIOM-Monitoring CPIOM-Monitoring device device resource resource I.A I.A for for scenario scenario 11 and and the the CPIOM-Monitoring device resource III.A for scenario 2. The configuration for resource I.A is CPIOM-Monitoring device resource III.A for scenario 2. The configuration for resource I.A is according CPIOM-Monitoring device resource III.A for scenario 2. The configuration for resource I.A is according Table and the configuration for III.A resource III.A is according Tableresource 2. Both resource to Table 1,to and the 1, configuration for resource is according to Table 2.to host the according to Table 1, and the configuration for resource III.A is according toBoth Table 2. Both resource host the same sub-application. same sub-application. host the same sub-application.

TTP TTP Fuel-level-display subFuel-level-display application subapplication START START COLD WARM COLD STOP WARM STOP

E_RESTART E_RESTART

INT INT

#MP_Addr #MP_Addr

MPSub MPSub INT0

INT REQ INT REQ

IND INT0 IND

ID

SUBL_1 SUBL_1 RD_1

ID

RD_1

MPWri MPWri

INT0 CNF INT0 CNF

IO_WRITER #Effector_ID #Effector_ID

ID IO_WRITER ID SD_1 SD_1

Fuel tank system (under control) Fuel tank system (under control) Execution scheduling of Function block(s) Execution scheduling of Function block(s) Figure 13. Configuration of resource I.A from CPIOM-Control device for scenario 1 and resource III.A Figure 13. Configuration of resource I.A from CPIOM-Control device for scenario 1 and resource III.A from CPIOM-Control device for scenario 2. CPIOM-Control device for scenario 1 and resource III.A Figure 13. Configuration of resource I.A from from CPIOM-Control device for scenario 2. from CPIOM-Control device for scenario 2.

5. Design and Analysis 5. Design and Analysis This section discusses the execution design and latency analysis approaches along with results This section discusses the execution design and latency analysis approaches along with results from timing metrics (based on the DAA scheduling). from timing metrics (based on the DAA scheduling).


15 of 30

5. Design and Analysis This section discusses the execution design and latency analysis approaches along with results from timing metrics (based on the DAA scheduling). 5.1. Execution Design The execution design method for the IEC61499-modelled DAA develops a scheduling approach for the DAA FBs. It consists of timing the execution of the above FBs in a way to guarantee the low end-to-end latency for the DAA to temporal dependability. The DAA scheduling approach is based on the execution time defined by synchronic clock ticks from the IMA-TTP platform (Section 3.2). It is for tasks and messages from the DAA under consideration. Each FB of the DAA IEC-61499 model is considered a task (periodic tasks with/without variable period) to be executed. Events and data sent from and to FBs are considered messages to be exchanged between FBs. The FB task structure is fully defined by the FB architecture (structure and behavior). Two static scheduling policies are considered: off-line scheduling and on-line scheduling. The former keeps the execution order for FBs, and the time (FBs are executed) is well defined in advance. The latter allows for changes in the execution order of FBs, although the order is mostly sequential. It is driven by precedent tasks and fixed task priorities. Both policies are non-preemptive and make subsequent inter-task communication with flawless synchronization between FB tasks possible (including mutual exclusion for computing resources). The executions of FBs are triggered by IMA-TTP platform ticks (every 1 ms) and enabled by FB events (which come along with FB data). Each IMA partition minor frame (RTOS partition slot) is of 10 ms. The TDMA round is 1 ms for the TTP. Both scheduling approaches (from IMA and TTP) are assumed to be synchronized so that full determinism is guaranteed at the computation and communication levels. The duration of each FB task is no longer than the period of the IMA-TTP platform tick (1 ms). FBs are scheduled so that their execution starts at an IMA-TTP platform tick in scenario 1 (1 ms) and just after the completion of the execution of the FB antecessor in scenario 2 (synchronized execution every 100 µs). The FB task deadline is the tick period in any scenario, and it is assumed to always be met by the FBs. Details of the duration of each sub-application FB are presented in Appendix B. Figure 14 presents four cases of execution for two FBs (computation of and communication between FB1 and FB2 (based on the FB execution timing [28]). Case A shows an example of on-line scheduling (only one partition). FB2 is executed in the next positive clock edge as soon as FB1 finishes. Case B shows an example of off-line scheduling (only one partition). FB2 is executed in the next IMA-TTP platform execution tick edge as soon as FB1 finishes. Case C shows an example of off-line scheduling (more than one partition). FB2 is executed in the next IMA-TTP platform execution tick edge (in a different partition or even device than FB1) as soon as FB1 finishes. Case D shows an example of off-line scheduling (one or more than one partition). FB2 is executed in the next IMA-TTP platform execution tick edge (in a different device than FB1) as soon as FB1 finishes. There is also a second execution of FB1, of which the output is not considered by the FB2 execution. This situation is handled in a similar way for any scheduling case (first-come, first-served basis for events-data enablers).

Aerospace 2018, 5, 15 Aerospace 2018, 4, x FOR PEER REVIEW

16 of 30 16 of 30

Case A

Case B

Case C

Case D

FB1 Task FB1 Input Data FB1 Input Events FB1 Output Data FB1 Output Events

Event inputs

PS

Event outputs

Execution Control Chart

Type identifier Internal variables

Data inputs

Algorithm 1

Data outputs

Algorithm 2

TTP

Algorithm k

Basic FB

FB2 Task FB2 Input Data FB2 Input Events FB2 Output Data FB2 Output Events FB Execution Tick Clock 0

1

2

3

4

5

6

7

8

9

10

Time [msec]

Figure14. 14. Examples Examples of ofexecutions executionsof ofFunction FunctionBlocks Blocks(FBs) (FBs)according accordingto tothe thescheduling schedulingapproaches. approaches. Figure

5.2.Latency LatencyAnalysis Analysis 5.2. Thetiming timingofofthe theDAA DAAscheduling schedulingdefined definedbybythe theexecution executiondesign design approach (Section 5.1) plays The approach (Section 5.1) plays a a key role to achieve time-related determinism. One of the relevant aspects of interest of timing the key role to achieve time-related determinism. One of the relevant aspects of interest of timing isisthe end-to-endlatency latencydefined definedby bytime timethat thattakes takesthe thedata dataflow flowto togo gothrough throughaapath pathdefined definedbetween betweenthe the end-to-end sensing elements and the effecting elements of the DAA. The timing metrics for the end-to-end sensing elements and the effecting elements of the DAA. The timing metrics for the end-to-end latency is as defined as follows: islatency defined follows: n −1

λ = ( f n − b n ) + ∑ ( bi − bi + 1 ) ) = ( − ) + i =1 ( − λ: end-to-end latency : end-to-end latency f n : finishing time for task (τn )n ( ) : finishing time forntask bi : beginning time for task i (τ i) i ( ) : beginning time for task n : total: amount of tasks for the flow considered (T = {( τ1= , τ2 , τ3, , . ., . τ,n… }) total amount of tasks forend-to-end the end-to-end flow considered

(1) (1)

)

The end-to-end end-to-end latency latency calculation calculation in in (1) (1) isis useful useful to to analyze analyze whether whether the the DAA DAA meets meets the the The temporal dependability requirements from a software-engineering viewpoint and the crosstemporal dependability requirements from a software-engineering viewpoint and the cross-discipline discipline impact of such a measurement on thestability control-loop from a control-engineering impact of such a measurement on the control-loop from astability control-engineering viewpoint [29]. viewpoint [29]. The latency analysis entails calculation of the worst-case flow latency bestThe latency analysis entails calculation of the worst-case flow latency and the best-case and flowthe latency. case flow They define the maximum and that minimum expectedoffrom They definelatency. the maximum and minimum latencies can belatencies expectedthat fromcan thebeexecution FBs.the execution of FBs. The above execution design method as well as the end-to-end latency analysis are applied to the The above designsoftware method application as well as the end-to-end latency analysis are applied to the ITT control in theexecution FMMS control (Section 4). They are discussed in the following ITT control for in the FMMS control software application (Section They are discussed in the following subsections off-line and on-line scheduling strategies in two4). scenarios. subsections for off-line and on-line scheduling strategies in two scenarios. 5.3. Scenario 1 5.3. Scenario 1 Sub-application FBs (as tasks) are sequentially and statically scheduled for the first strategic Sub-application FBs (as are 1a. sequentially statically the of firstthe strategic scheduling configuration in tasks) scenario Figure 15and shows how scheduled FBs from for parts DAA scheduling configuration in scenario 1a. Figure 15 shows how FBs from parts of the DAA subapplications (that make possible the control of the mid pump) are scheduled. All the FBs are executed


17 of 30


17 of 30

sub-applications (that make possible the control of the mid pump) are scheduled. All the FBs are in partition I of each The CPIOM partitions (minor frame) areare allallconsidered executed in partition I ofCPIOMs. each CPIOMs. The CPIOM partitions (minor frame) consideredto to be synchronized by means of the TTP (TDMA round). Executions of FBs are clearly separated from each other by means of execution ticks of 1 ms. Partition I FPan

Fuel-cockpit-panel

IRPub

Partition I (CPIOM-Control)

IRSub

Control-command

IRSam

INT

INT0 IND

COLD WARM STOP

IN T REQ

SCAN START

INT REQ

INT0 CNF

t#1ms

100

INT0 CNF

SPI

ID

SP

#I L_Addr RD_1

Data-concentration

RD_1

SAMPLE_UINT IN

FB_REAL_UNIT

OUT

IN

PUB_1

IO_READER ID

CNF

SUBL_1

E0

#Sens or _ID

E_CYCLE

ILSam

REQ

CNF

FACEPLATE

ILPub

ILAcq

START

E_RESTART

INT0 IND

IRSam REQ

ILAcq


ILSub

FPan INT

OUT

MPPI DC

ID SD_1

REQ

DT

START COLD WARM STOP

ILPub

0

FB_PIDR True

E_REND

MPQue

REQ

MPPub

CNF

INT REQ

IN

OUT

2. 5

INT0 CNF

t#250ms t#1s t#0s


XOUT

PUB_1

FB_REAL_UNIT

ILSub

Partition I (CPIOM-Sensing)

EO

EI1 EI1 R

E_RESTART

TTP

CNF

RENDEZVOUS

ID SD_1

ILSam Control-command MPPIDC

START

MPWri

MPSub

COLD WARM STOP

INT

E_RESTART

INT0 IND

INT REQ

SUBL_1 #MP_Addr

ID

MPQue

RD_1

INT0 CNF

IO_WRITER #Effector_ID

ID SD_1


MPPub TTP Fuel-level-display

MPSub

Partition I (CPIOM-Monitoring)

MPWri 0

1

2

3

4

5

6

7

8

9

10

Time [msec]

Figure (ITT) control. control. Figure 15. 15. Scheduling Scheduling strategy strategy 1a 1a of of the the FBs FBs for for the the Inner Inner Transfer Transfer Tank Tank (ITT)

The fuel-cockpit-panel sub-application and the data-concentration sub-application are executed in different different CPIOMs. CPIOMs.Thus, Thus,their theirFBs FBscan canbebeexecuted executed same time (0–2 ms). messages atat thethe same time (0–2 ms). TheThe TTPTTP messages are are separated in time as come they come from different CPIOMs (2–3 and have assigned unique separated in time as they from different CPIOMs (2–3 ms) andms) have assigned unique sending sending time slots. Equation (1) for14Figure 14 is calculated as follows: time slots. Equation (1) for Figure is calculated as follows: )+( )+ ) =( − − − +( − λ1a = ( f MPSub − b MPSub ) + ( f MPWri − b MPWri ) + (b I IPub − b ILAcq ) + (bTTP − b I IPub ) )+( )+( ) − − − + (b +( (2) ILSub − bTTP ) + ( b ILSam − b ILSub ) + ( b MPPIDC − b ILSam ) (2) ) − + − +( − + +(b MPQue − b MPPIDC ) + (b MPPub − b MPQue ) + (bTTP − b MPPub ) ) +( − +( b MPSub − bTTP ) Equation (2) can be simplified since the beginning and finishing times are the same for all the Equation (2)Hence, can be it simplified sincethe thesummation beginning and finishing are the same (nine for allin the FBs FBs but MPSub. just becomes of all the FB times execution periods total) but MPSub. Hence, just becomes the summation of all the FB execution periods (nine in total) plus the duration of itthe MPSub FB (0.2 ms as supposed). Therefore, the end-to-end latency is: plus the duration of the MPSub FB (0.2 ms as supposed). Therefore, the end-to-end latency is: (3) = 1 × 9 + 0.2 = 9.2 ms 1 × 9 + 0.2 and = 9.2dynamically ms (3) 1a =sequentially Sub-application FBs (as tasks) λare scheduled for the second strategic scheduling configuration in scenario 1b. FBs are dispatched as their required previous FB Sub-application FBs (as tasks) are sequentially and dynamically scheduled for the second strategic finishes its execution and the output is available. The enabler (for FB dispatch) is the event signal scheduling configuration in scenario 1b. FBs are dispatched as their required previous FB finishes its coming from the FB antecessor. Thus, the scheduling rules are driven by the FBs. Figure 16 shows execution and the output is available. The enabler (for FB dispatch) is the event signal coming from how FBs from parts of the DAA sub-applications (that makes possible the control of the mid pump) the FB antecessor. Thus, the scheduling rules are driven by the FBs. Figure 16 shows how FBs from are scheduled. parts of the DAA sub-applications (that makes possible the control of the mid pump) are scheduled.


18 of 30


18 of 30 Partition I

FPan Partition I (CPIOM-Control)

Fuel-cockpit-panel


Control-command

Partition I (CPIOM-Sensing)

Data-concentration


Control-command

Partition I (CPIOM-Monitoring)

Fuel-level-display

IRPub IRSub IRSam End-to-end latency

ILAcq ILPub TTP ILSub ILSam MPPIDC MPQue MPPub TTP MPSub MPWri 0

1

2

3

4

5

6

7

8

9

10

Time [msec]

Figure Figure 16. 16. Scheduling Scheduling strategy strategy 1b 1b of of the the FBs FBs for for the the ITT ITT control. control.

All the theFBs FBsfor forthe the control of the pump are executed now executed in a shorter time. Thus, it is control of the midmid pump are now in a shorter time. Thus, it is expected expected that the end-to-end is smaller. However, theofpoint of this scheduling approach to that the end-to-end latency islatency smaller. However, the point this scheduling approach is to beis an be an alternative thepresented one presented and show that an event-driven execution the can FBsalso can alternative to theto one aboveabove and show that an event-driven execution of theofFBs also by providing determinism complying the timing requirements. Equation (2) workwork well well by providing determinism and and complying withwith the timing requirements. Equation (2) for for Figure is calculated as follows: Figure 15 is15calculated as follows: = (9.25 − 9.0) + (9.3 − 9.25) + (0.55 − 0) + (1.1 − 0.55) + (1.55 − 1.10) λ1b = (9.25 − 9.0) +(9.3 − 9.25) + (0.55 − 0) + (1.1 − 0.55) + (1.55 − 1.10) + (1.75 − 1.55) + (2.00 − 1.75) + (2.75 − 2.00) + (3.00 − 2.75) +(1.75 − 1.55) + (2.00 − 1.75) + (2.75 − 2.00) + (3.00 − 2.75) + (3.20 − 3.00) + (3.30 − 3.20) = 3.5 ms +(3.20 − 3.00) + (3.30 − 3.20) = 3.5 ms

(4) (4)

5.4. Scenario 2 Sub-application Sub-application FBs FBs (as (as tasks) are sequentially and statically scheduled scheduled for the first strategic scheduling configuration in scenario 2a. Figure 17 shows how FBs fromfrom partsparts of the subscheduling configuration in scenario 2a. Figure 17 shows how FBs of DAA the DAA applications (that(that make possible the control of the pump) are scheduled. sub-applications make possible the control of mid the mid pump) are scheduled. DAA functionalities functionalitiesare are distributed in different partitions in scenario usepartitions of more distributed in different partitions in scenario 2a. The2a. use The of more partitions makes the end-to-end latency due to execution the partition execution FBs eventuallyeventually makes the end-to-end latency longer due tolonger the partition times. FBs are times. scheduled are perthey partitions as they are shown per scheduled partitions as are shown in Figure 15. in Figure 15. Equation (2) can can be besimplified simplifiedsince sincethe thebeginning beginningand andfinishing finishing times FBs overwritten times forfor FBs areare overwritten by by time batches defined by IMA the IMA partitions. AllFBs thebut FBsMPSub but MPSub and MPWri comply with the time batches defined by the partitions. All the and MPWri comply with the above above constraint. Thus, Equation (2) becomes the summation of the two partition time timingtiming constraint. Thus, Equation (2) becomes the summation of the two partition time slots andslots the and the duration of the MPSub FB (0.2 ms as supposed). Therefore, the end-to-end latency is duration of the MPSub FB (0.2 ms as supposed). Therefore, the end-to-end latency is (5) = 10 + 10 + 0.2 = 20.2 λ2a = 10 + 10 + 0.2 = 20.2 ms (5) Sub-application FBs (as tasks) are sequentially and dynamically scheduled for the second Sub-application (as tasks) are scheduled the second strategic strategic scheduling FBs configuration in sequentially scenario 2b.and FBsdynamically are dispatch as their for required previous FB scheduling configuration in scenario 2b. FBs are dispatch as their required previous FB finishes its finishes its execution and the output is available. The enabler (for FB dispatch) is the event signal coming from the FB antecessor. Figure 18 shows how FBs from parts of the DAA sub-applications (that make possible the control of the mid pump) are scheduled.


19 of 30

execution and the output is available. The enabler (for FB dispatch) is the event signal coming from the FB antecessor. Figure 18 shows how FBs from parts of the DAA sub-applications (that make possible the control mid pump) are scheduled. Aerospace 2018,of 4, the x FOR PEER REVIEW 19 of 30 Aerospace 2018, 4, x FOR PEER REVIEW

19 of 30

Partition I

Partition II

Partition I

FPan

Partition III

Partition II

FPan IRPub

START INT

START E_RESTART COLD WARM STOP

IRPub Partition switch Partition

INT0 IND

INT SPI

SPI

Fuel-cockpit-panel Fuel-cockpit-panel Partition I (CPIOM-Control) Partition I

INT0 CNF

INT REQ MPPub

FPan

100

100

Partition III

MPPub

FPan

COLD WARM STOP

FACEPLATE

INT0 SP IND

INT REQ ID

PUB_1

INT0 CNF

(CPIOM-Control)

SD_1

E_RESTART

FACEPLATE

PUB_1 SP

ID SD_1

ILSub

IRSub INT0 IND

INT

switch IRSub

SUBL_1

INT0 IND

IRSam REQ

IRSub INT ID

INT

INT0 IND RD_1

CNF

ILSam

REQ

ILSub INT ID

IRSam

REQ IN

SUBL_1 ID

INT0 IND RD_1

ILSam

REQ IN

SUBL_1

RD_1

START

ID

COLD WARM STOP

INT REQ

SCAN STA RT

COLD WARM STOP

ILAcq ILPub

#S ensor_ID

E_CYCLE SCAN

t#1ms

DT STA RT

INT ID REQ

INT0 #I L_Addr CN F RD_1

ID INT REQ

#S ensor_ID

E_CYCLE

#I L_Addr

ID RD_1

True

EO

MPPub E_REND

CNF

INT REQ

INT0 CNF

ID

MPQue

SD_1

DT

MPPub

FB_REAL_UNIT

REQ

IN

CNF

OUT

INT REQ ID

OUT

PUB_1INT0 CNF

SD_1

Data-concentration Partition I (CPIOM-Sensing) Partition I (CPIOM-Sensing)

PUB_1

FB_REAL_UNIT IN

(CPIOM-Control) Data-concentration

FB_PIDRCNF AUTO XOUT PV SP FB_PIDR XO AUTO XOUT True KP 2. 5 PV DT t#250m s SP TR t#1 s XO t#0 s TD KP 2. 5 DT t#250m s TR t#1 s t#0 s TD REQ

E_REND

EI1 EI1 R

MPQue

REQ

ILPub TTP

CNF MPPI DC

EO

EI1 EI1 R RENDEZVOUS

E_RESTART

PUB_1

REQ

IN RENDEZVOUS OUT

0

0

E0

IO_REA DER

t#1ms

OUT

COLD WARM STOP

INT0 CNF

SD_1

IN

MPPI DC

FB_REAL_UNIT

START E_RESTART

PUB_1 ILPub

ILAcq IO_REA DER

E_RESTART

INT0 CNF

INT REQ

INT0 CN F

E0

START

CNF OUT

RD_1

COLD WARM STOP

ILPub

ILAcq

START

E_RESTART

Control-command Partition II (CPIOM-Control) Partition II

FB_REAL_UNIT

CNF OUT

SAMPLE_UINT

IRSam ILAcq

Control-command

CNF

SUBL_1

SAMPLE_UINT

IRSub IRSam

ID SD_1

TTP ILSub ILSub ILSam ILSam MPPIDC MPPIDC MPQue MPQue

START

START E_RESTART COLD WARM STOP

MPWri

MPSub

COLD WARM STOP

INT

INT0 IND

IN T REQ MPWri

MPSub

#MP_ Addr

INT ID

SUBL_1

INT0 RD_1 IND

IN T0 CN F

#Effector_ID

IN T REQ ID

IO_WRITER IN T0 CN F

SD_1

E_RESTART

SUBL_1 #MP_ Addr

ID

RD_1


ID

Control-command Control-command Partition II (CPIOM-Control) Partition II (CPIOM-Control)

SD_1

MPPub MPPub TTP TTP MPSub MPSub MPWri MPWri

0 0

5 5

10 10

15 Time15 [msec] Time [msec]

20 20

25 25

Fuel-level-display Fuel-level-display Partition I (CPIOMMonitoring) Partition I (CPIOMMonitoring) 30 30

Figure strategy 2a of the FBs for the ITT control. Figure 17. 17. Scheduling Scheduling strategy strategy 2a 2a of of the the FBs FBs for for the the ITT ITT control. control. Figure 17. Scheduling Partition I Partition I

FPan FPan

Partition II Partition II

Partition III Partition III

Partition I (CPIOM-Control) Partition I (CPIOM-Control)

IRPub IRPub Partition Partition switch switch IRSub IRSub

Fuel-cockpit-panel Fuel-cockpit-panel

Partition II (CPIOM-Control) Partition II (CPIOM-Control)

IRSam IRSam ILAcq ILAcq

Control-command Control-command

Partition I (CPIOM-Sensing) Partition I (CPIOM-Sensing)

ILPub ILPub

Data-concentration Data-concentration

TTP TTP ILSub ILSub ILSam ILSam MPPIDC MPPIDC

Partition II (CPIOM-Control) Partition II (CPIOM-Control)

Control-command Control-command

MPQue MPQue MPPub MPPub TTP TTP MPSub MPSub

Partition III (CPIOM-Monitoring) Partition III (CPIOM-Monitoring)

MPWri MPWri 0 0

5 5

10 10

15 15 Time [msec] Time [msec]

20 20

25 25

Fuel-level-display Fuel-level-display 30 30

Figure 18. Scheduling strategy 2b 2b of the the FBs for for the ITT ITT control. Figure Figure 18. 18. Scheduling Scheduling strategy strategy 2b of of the FBs FBs for the the ITT control. control.

The from Figure 16 for each partition, i.e., FBs are dispatched The scheduling follows aa pattern pattern The scheduling of of FBs FBs follows pattern from from Figure Figure 16 16 for foreach eachpartition, partition,i.e., i.e.,FBs FBsare aredispatched dispatched as their antecessors finish their execution. The end-to-end latency is expected to be similar to the one as their their antecessors finish their execution. The end-to-end as end-to-end latency latency is is expected expectedto tobe besimilar similarto tothe theone one provided in Figure Figure 17. 17. Therefore, Therefore, itit does does make make sense sense that that Equation Equation (2) (2) provided by by the the scheduling scheduling approach approach in provides the same result than in scenario 1b (scheduling strategy 1b) when FBs are dispatched as provides the same result than in scenario 1b (scheduling strategy 1b) when FBs are dispatched as their antecessors finish their execution since the execution timing is still defined by the IMA their antecessors finish their execution since the execution timing is still defined by the IMA partitions. 18 is is partitions. Thus, Thus, Equation Equation (2) (2) for for Figure Figure 18 = 10 10 + + 10 10 + + 0.2 0.2 = = 20.2 20.2 ms ms =

(6) (6)


20 of 30

provided by the scheduling approach in Figure 17. Therefore, it does make sense that Equation (2) provides the same result than in scenario 1b (scheduling strategy 1b) when FBs are dispatched as their antecessors finish their execution since the execution timing is still defined by the IMA partitions. Thus, Equation (2) for Figure 18 is λ2b = 10 + 10 + 0.2 = 20.2 ms


20 of (6) 30

FBs FBs(tasks) (tasks)are arerequired requiredto tobe be executed executedwithin withinthe thecycle cycle(1 (1ms). ms). Thus, Thus,the thedeployment deploymentof ofFBs FBsisis scheduled scheduledin inaaway wayno noFB FB (task) (task)finishes finishesafter after the the above above cycle. cycle. They Theyare aremeant meantto tohave haveaastart starttime time that thatmeets meetsthe thecycle cycletick. tick.However, However,they theyare areallowed allowedto tostart startafter after(not (notbefore) before)each eachtick, tick,but butthey theymust must finish finishjust justbefore before(sooner (soonerthan) than)the theend endof of the the cycle cycle (deadline) (deadline) to to allow allow for for communication communicationbetween between FBs. even though thethe IMA platform is fully reliable to meet timing. It FBs.The Theabove abovetask taskjitter jitterisisallowed allowed even though IMA platform is fully reliable to meet timing. would notnot be be a problem if aiftask finishes after the cycle It would a problem a task finishes after the cyclesince sinceexecutions executionsofofFBs FBsare aretriggered triggeredby byticks ticks but butalso alsoenabled enabledby byevents. events.Therefore, Therefore,an anFB FBisisnot notexecuted executedby bythe thetick tickififno noinput inputevent event(that (thatinvoke invoke the theFB) FB)isispresent. present.AAsimilar similarsituation situationoccurs occurswith withmessages messagesin inthe theTTP TTPplatform. platform.Messages Messagesconsist consistof of event eventand anddata. data.Node Nodebroadcast broadcastcan canhappen happenatatany anypoint pointin inthe theTDMA TDMAround. round.The TheTTP TTPplatform platformisis fully fullyreliable. reliable.However, However,any anymissing missingor ordelayed delayedmessage message(beyond (beyondTDMA TDMAround) round)will willnot nottrigger triggerthe the linked linkedFB(s), FB(s),so soFB FBexecution executionsynchronization synchronization is is guaranteed. guaranteed. ControlPerformance Performance 6.6.Control This section sectionpresents presentsthe themodeling modelingand andsimulation simulationof ofthe theDAA DAAcontrol controlloop loopand and aa study study the the This impact of the end-to-end latency (due to the DAA execution) on the stability of such a loop. impact of the end-to-end latency (due to the DAA execution) on the stability of such a loop. 6.1.Control ControlLoop LoopModel Model 6.1. Theresults resultsfrom fromthe theend-to-end end-to-end latency analysis scenario 1 and 2 (Sections 5.3 5.4) and can 5.4) The latency analysis forfor scenario 1 and 2 (Sections 5.3 and can be evaluated across engineering discipline (from a control-engineering viewpoint) by means be evaluated across engineering discipline (from a control-engineering viewpoint) by means of crossof cross-checking impact of such latency the DAA control is a way verify checking the impactthe of such a latency onathe DAA on control loop. This is a loop. way toThis verify that thetolatency that the latency (due to execution of FBs) does not affect the DAA performance since the DAA (due to execution of FBs) does not affect the DAA performance since the DAA is temporallyis temporally dependable. dependable. Theend-to-end end-to-endlatency latencyisisthe thetime timeelapsed elapsed between sensors and effectors a control system. The between sensors and effectors in aincontrol system. It It considers all the flow latencies encountered along the sensor-effector path. Figure 19 shows the considers all the flow latencies encountered along the sensor-effector path. Figure 19 shows the endend-to-end latency forDAA the DAA sub-applications (focus on ITT the ITT as scheduled) a block diagram to-end latency for the sub-applications (focus on the as scheduled) on aon block diagram (a (a from control engineering viewpoint). It includes two TTP blocks and a Partition Switch (PS) block. from control engineering viewpoint). It includes two TTP blocks and a Partition Switch (PS) block. IRSub

ILSub

INT

INT

INT0 IND

INT

INT REQ

INT0 IND

ILSam

REQ

CNF

ID

START

RD_1

SAMPLE_UINT IN

IN

FACEPLATE 100

SPI

PUB_1 SP

OUT

MPPI DC

REQ

CNF

0

EI1 EI1 R

E_RESTART

True

E_REND

MPPub

CNF

INT REQ

2. 5

INT0 CNF

t#250m s t#1s t#0s

OUT

RD_1

INT REQ


IN T0 CNF


ID SD_1

XOUT

PUB_1

FB_REAL_UNIT IN

ID

FB_PIDR

MPQue

REQ

MPWri INT0 IND

SUBL_1 #MP_Addr

EO

ID SD_1

INT

E_RESTART

RENDEZVOUS

COLD WARM STOP

MPSub

COLD WARM STOP

FB_REAL_UNIT

OUT

INT0 CNF START

E_RESTART

CNF

SUBL_1 RD_1

MPPub

FPan

COLD WARM STOP

INT0 IND

IRSam REQ

SUBL_1 ID

START

ID SD_1

End-to-end latency

a

c

Fuel-cockpitb panel Sub-application

d PS

e

f

+ e

-

g Control- h command sub-application

i

j TTP

d COLD WARM STOP

INT REQ

SCAN START

E_RESTART

E0

PUB_1

IO_REA DER #Sensor _ID

E_CYCLE t#1ms

#IL_Addr

ID RD_1

Inner Transfer Tank k

a

INT0 CNF

INT REQ

INT0 CNF

Effector Commands

Sensors

ILPub

ILAcq

START

ID SD_1

DT

TTP c

b Dataconcentration sub-application

Triggering Time [msec]

Fuel-levelk display sub-application

Scenario 1

Scenario 2

(a)

(b)

(a)

a

0

0

0

b

1

*0.55

1

(b) 0 +

0.55

+

2.1

c

2

*1.1

2.1

d

3

*1.55

10.1

e

4

*1.75

11.1

f

5

2

12

11.4

g

6

2.75

13

11.65

h

7

3

14

11.85

i

8

3.2

15.3

15.3

J

9

3.3

20

20

k

9.2

3.5

20.2

20.2

+

10.2

+

10.65

For the reference signal (Fuelcockpit-panel): * b=0.45, c=1, d=1.1, e=1.3 + b=0.45, c=2, d=10, e=10.4

Figure Figure19. 19.End-to-end End-to-endlatency latencyininthe thecontrol controlloop loopofofthe theDistributed DistributedAvionics AvionicsApplication Application(DAA). (DAA).

The table on the right of Figure 19 shows the triggering times for the tasks (execution of FBs) as scheduled by the two static scheduling strategies in the two scenarios. There is a slight different in the triggering times for b, c, d, and e for the reference signal (input of Fuel-cockpit-panel), as specified in the table below. The end-to-end latency of the DAA execution has an impact on the control stability of the FMMS. It is expected that long end-to-end latencies make the FMMS more unstable, whilst shorter ones do


21 of 30

The table on the right of Figure 19 shows the triggering times for the tasks (execution of FBs) as scheduled by the two static scheduling strategies in the two scenarios. There is a slight different in the triggering times for b, c, d, and e for the reference signal (input of Fuel-cockpit-panel), as specified in the table below. The end-to-end latency of the DAA execution has an impact on the control stability of the FMMS. It is expected that long end-to-end latencies make the FMMS more unstable, whilst shorter ones do not have any change in the FMMS stability (from the control viewpoint). The above latency is incorporated in the control model (block diagram) of the FMMS to investigate the impact of such a delay in the control Figure shows the above model for the FMMS (only ITT and IEFT control). Aerospaceloop. 2018, 4, x FOR 20 PEER REVIEW 21 of 30

Figure20. 20.Control Controlmodel modelof ofthe theFuel FuelMeasurement Measurementand andManagement ManagementSystem System(FMMS). (FMMS). Figure

The Themodel modelof ofthe theFMMS FMMSisisaatypical typicalblock blockdiagram diagramthat thatconsists consistsofofthe thesystem systemunder undercontrol control (Airbus rig)and anditsitscontroller controller (Proportional-Integral-Derivative or PID controller). (AirbusA380-800 A380-800 fuel rig) (Proportional-Integral-Derivative or PID controller). The The controller tuned to meet non-official specifications and its tuning process the PIDPID controller waswas tuned to meet non-official specifications and its tuning process is outisofout theofscope scope this paper. The former is represented two triangle-shaped theofgain of the two of thisofpaper. The former is represented by twobytriangle-shaped blocksblocks for thefor gain the two pumps pumps (Mid Pump and Transfer Pump), signal summation points(circles), (circles),and and two square-shaped (Mid Pump and Transfer Pump), twotwo signal summation points square-shaped blocks integrators. Additionally, therethere are two blocks for the tank-level reference blocksfor forthethe integrators. Additionally, aresquare-shaped two square-shaped blocks for the tank-level signals for signals each tank Set and Transfer Pump Set points desired levels), a random reference for(Mid each Pump tank (Mid Pump Set and Transfer Pumpfor Settheir points for their desired levels), signal generator along with a transport-delay block to simulate the behavior of the engine 2 pump, a random signal generator along with a transport-delay block to simulate the behavior of the engine and two square-shaped blocks forblocks each offor the control loops (theloops top one forone the is mid and the 2 pump, and two square-shaped each of the control (theistop forpump the mid pump bottom is for one the transfer to specify thespecify latencythe introduced by part of the DAAofexecution. and theone bottom is for thepump) transfer pump) to latency introduced by part the DAA The controller included in the command execution. Theiscontroller is included in thesub-application. command sub-application. 6.2. 6.2.Control ControlStability StabilityAnalysis Analysis The TheFMMS FMMSstability stabilitycan canbe beanalyzed analyzedininthe thefrequency frequencydomain. domain.The Thefrequency frequencyresponse responseof ofthe the control open loop) for the application provides valuable information about the system controlsystem system(at(at open loop) for DAA the DAA application provides valuable information about the stability by means of the gain and phase margin. The open-loop control model for the ITT control system stability by means of the gain and phase margin. The open-loop control model for the ITT entails: the PIDthe controller, the TTP and the TheThe magnitude and phase forforthe control entails: PID controller, thedelay, TTP delay, andITT. the ITT. magnitude and phase theabove above application applicationisiscalculated calculatedas asfollows: follows: For Formagnitude magnitude M = 20log|C (s) G (s)| (7) (7) = 20 | ( ) ( )|

where the Transfer Function (TF) for the PID controller is ( )=

0.03817

+ 4.923 + 11.51

(8)

The TF for the ITT is ( )=

2

(9)


22 of 30

where the Transfer Function (TF) for the PID controller is C (s) =

0.03817s2 + 4.923s + 11.51 s

(8)

2 s

(9)

The TF for the ITT is G (s) = And Then

s = jω

(10)

! 0.03817( jω )2 + 4.923jω + 11.51 2 20log|C ( jω ) G ( jω )| = 20log jω jω 0.07634ω 2 − 23.02 9.846 = 20log − j ω ω2

(11)

For phase P = ∠C ( jω ) G ( jω ) = − tan

−1

− 9.846 ω 0.07634ω 2 −23.02 ω2

!

= − tan

−1

−9.846ω 0.07634ω 2 − 23.02

(12)

Then, the Gain Margin (ω g = 0 rad/sec is the phase crossover frequency) 1 1 = 20log GM = 20log 0.03817( jωg )2 +4.923jωg +11.51 C jω g G jω g jω g

2 ωg

= −∞ dB

(13)

And, the Phase Margin (ω p = 9.97 rad/s is the gain crossover frequency) PM = 180◦ − ∠C jω p G jω p = 180◦ 2 0.03817( jω p ) +4.923jω p +11.51 2 −9.846ω p −1 −∠ = 180 − tan ωp jω p 0.07634ω 2 −23.02

(14)

p

= 81.1 deg Figure 13 shows the variation of the gain and phase margins according to the range of latencies due to the DAA execution. The above margins allow for analysis for the FMMS stability. The greater margins are the more stable the FMMS is. It is clear from Figure 21 that the margins are smaller as the latency increased. The FMMS is stable along the latency spectrum.

0.07634

− 23.02

= 81.1 Figure 13 shows the variation of the gain and phase margins according to the range of latencies due to the DAA execution. The above margins allow for analysis for the FMMS stability. The greater Aerospace 15 more stable the FMMS is. It is clear from Figure 21 that the margins are smaller 23 ofas30 margins2018, are5,the the latency increased. The FMMS is stable along the latency spectrum.

90 80

GM [Db], PM [Deg]

70

81.1 80.5 79.9 79.3 78.8 78.2 77.6 77.1 76.5 75.9 75.4 74.8 74.2 73.6 73.1 72.5 71.9 71.4 70.8 70.2 69.6 69.1 68.5 67.9 67.4 66.8 66.2 65.6 65.1 64.5

60 50 Gain Margin

40

Phase Margin

30 20

22.3 22.3 22.3 22.2 22.1 22.1 21.9 21.8 21.7 21.5 21.3 21.1 20.8 20.6 20.3 20.1 19.8 19.5 19.2 18.9 18.6 18.2 17.9 17.6 17.3

17

16.7 16.4 16.1 15.8

10 0 1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Latency [msec]

Figure 21. Gain and phase margins as indexes of control stability. Figure 21. Gain and phase margins as indexes of control stability.

TheGM GM and and PM msms areare of of particular interest, since theythey are the and The PM for for1.5 1.5ms msand and8.8 8.8 particular interest, since areminimum the minimum maximum latencies (best-case flowflow latency and worst-case flow latency) for thefor forward controlcontrol path and maximum latencies (best-case latency and worst-case flow latency) the forward (latency  for the forward TFs: controller and rig TFs). These latencies are calculated as follows path (latency λ f k for the forward TFs: controller and rig TFs). These latencies are calculated as follows (fromtable tableininFigure Figure11): 11): (from n o

λ f kmin = min λ ak − a f n o λ f kmax = max λ ak − a f

(15)

(16)

where λ ak : end-to-end latency from ‘a’ to ‘k’ (control loop latency). λ a f : end-to-end latency from ‘a’ to ‘f’ (feedback loop latency). λ f k : end-to-end latency from ‘f’ to ‘k’ (forward path latency). The GM = 22.3 dB and PM = 80.2 deg for 1.5 s, and the GM = 21.7 dB and PM = 76.1 deg for 8.8 s. 6.3. Closed-Loop Control Response Performance The latency also has an impact in the time response (to a step input) of the control system (at closed loop) for the DAA application. The closed-loop TF (considering the two latencies λ f k and λ a f ) for the FMMS is Gcl (s) =

C (s ) × G (s ) × e−λ f k s 1 + C (s ) × G (s ) × e−λ a f s

=

0.07634s2 +9.846s+23.02 × e−λ f k s s 2 +23.02 × e−λ a f s 1 + 0.07634s +9.846s s −λ f k s

0.07634s2 + 9.846s + 23.02 × e = 0.07634s2 + 9.846 + eλa f s s + 23.02 e−λa f s

(17)

where the output (for an input signal X(s)) of the FMMS at closed loop in the frequency domain is Y (s) = Gcl (s) × X (s)

(18)


24 of 30

If the X(s) is the step signal, then the Laplace Transform of X (s) = 1s . Then, 

 0.07634s2 + 9.846s + 23.02 × e−λ f k s 1   Y (s) = λ s − s s 0.07634s2 + 9.846 + e a f s + 23.02 e a f

(19)

The FMMS output in the time domain is defined as follows (by applying the inverse Laplace transform):   2 + 9.846s + 23.02 × e−λ f k s 0.07634s y(t) = L−1 {Y (s)} = L−1  0.07634s3 + 10.846 + eλa f s s2 + 23.02 e−λa f s   

(20)

The change in the FMMS stability can be seen through the FMMS response to the step signal, given by y(t) in Equation (20), by means of the following characteristics the time domain: overshoot, settling time, and rise time. The less stability usually means larger overshoots, shorter settling times, and shorter rise times. Figure 22 shows the time response (time domain) for a latency of 3.5 ms and 20.2 ms (the latency range provided by the DAA execution). The step input is normalized to a value of 1. There is a slight change on the overshoot (increment) as the GM and PM are reduced. A comparison between characteristics of the FMMS response without and with latency for the worst cases (longer times and larger overshoots) shows that a variation of (1) the rise time of 0.027 s decrement (scenario 1b, deterioration), (2) the settling time of 0.0732 s decrement (scenario 1b, improvement), (3) the overshoot of 1.81% increment (scenario 2b, deterioration). Aerospace 2018, 4, x and FOR PEER REVIEW 24 of 30 Step Response

1.4

1.2

Scenario 1a Scenario 1b Scenario 2a Scenario 2b No latency

Overshoot Settling Time

1

Amplitude

0.8

Rise Time

0.6

0.4

Scenario

λ fk [msec]

λ af [msec]

No latency 1a 1b 2a 2b

0 4.2 1.5 8.2 8.8

0 5 2 12 11.4

Rise Time [sec] Settling Time [sec] Overshoot [%] 0.1586 0.1497 0.159 0.1316 0.1316

1.1624 1.1181 1.1326 1.0892 1.0903

12.7596 13.4837 13.0058 14.5689 14.57

0.2

0 0

0.2

0.4

0.6

0.8

1 Time (seconds)

1.2

1.4

1.6

1.8

2

Figure 22. 22. Time response for for an an input input (desired (desired level) level) for for the the mid mid pump. pump. Figure Time response

7. Discussion 7. Discussion This section discusses the experimental results obtained and a comparison of the IEC-61499 This section discusses the experimental results obtained and a comparison of the IEC-61499 standard with other modeling approaches for DAAs. standard with other modeling approaches for DAAs. 7.1. Experimental Results The results obtained in Sections 5 and 6 show it can be possible to support timing constraints when executing FBs from a DAA in a fully-deterministic (computation and communication) platform. The example makes use of the IMA and TTP technologies to provide full determinism through time partitioning and time triggering. Current IMA realizations in aircraft are connected by means of ADFX which provide a good degree of determinism by means of network calculus for latencies and jitters (bounded delays).


25 of 30

7.1. Experimental Results The results obtained in Sections 5 and 6 show it can be possible to support timing constraints when executing FBs from a DAA in a fully-deterministic (computation and communication) platform. The example makes use of the IMA and TTP technologies to provide full determinism through time partitioning and time triggering. Current IMA realizations in aircraft are connected by means of ADFX which provide a good degree of determinism by means of network calculus for latencies and jitters (bounded delays). The DAA is simple, but it is enough to show how FBs can be scheduled and executed in order to meet RT requirements such as end-to-end flow latency. The DAA scheduling is trivial (sequential and non-preemptive scheduling). Parallelism only happens for execution of FBs in different devices (CPIOMs). The key of the runtime approach is to execute the (local) FBs synchronously as well as to have deterministic communication to reach global synchronization. Scenario 1a (first strategy, off-line scheduling and one partition per CPIOM) shows that deterministic execution of FBs where partitions from different CPIOMs are synchronously executed at a time. Tasks (with a similar purpose, e.g., inputs of the controller) are executed in parallel in the same execution period when CPIOMs are different (0–2 ms) and one just after the other when the CPIOM is the same (3–5 ms). Scenario 1b (second strategy, on-line scheduling and subsequently continuous execution of FBs) shows that the same FBs can be all executed one after the other with obvious reduction of the end-to-end latency. The reduction is about the 62%. However, a faster completion of the end-to-end timing process does not mean more determinism or even better RT performance. Task execution jitters change the total process time. Scenario 2a (first strategy, off-line scheduling and three partitions used in CPIOM-Control) shows that scenario 1a can be also deployed in more than one partition in the same CPIOM. The end-to-end latency is increased as the partitions must be switched for consecutive execution. Scenario 2b (second strategy, on-line scheduling, three partitions used in CPIOM-Control, and subsequently continuous execution of FBs) shows that scenario 1b can also be deployed in more than one partition in the same CPIOM. The end-to-end latencies in scenario 2a and 2b are the same since partitions dictate the elapsed time for the DAA execution. The end-to-end latency calculus is rather defined by time slots than for the completions, jitters, or any other delays of the FB tasks. The variation of latency given by the range calculated is very small, and its impact on the RT performance of the DAA can be reflected in the control performance. Both scenarios involve non-preemptive scheduling (no chance of interruption whatsoever on the execution of tasks). This situation could well happen in avionics systems for more complex DAAs. Thus, further investigation is required to study preemptive scheduling (particularly, when the number of FB tasks is incremented). The execution design method absolutely depends on the available computing resources in any case. Nevertheless, the case study presented does not consider parallel computing from multicore processors, Field Programmable Gate Arrays (FPGAs), or Programmable Logic Devices (PLDs) for real computing parallelism. The control performance analysis demonstrates that the end-to-end latency impact on the control loop of the DAA is insignificant. A latency of 20.2 ms means 1.81% more of the overshoot (14.2% change from overshoot without delay) in the time response, which also means a drop of the GM from infinity to 22.3 dB, and 14.3% reduction of the PM. The former tightens the maximum gain (to 22.3 dB) that can be added to the control loop before it becomes unstable. The above results mean that the DAA is stable even though an execution latency is introduced. They are only indicative values for a range of possible execution configurations of FBs. However, they are a way to show that the DAA execution can be temporally effective and efficient if it is executed as a fully deterministic platform. This demonstration is just a preliminary idea that requires further tests via computer simulations as well as laboratory prototypes.


26 of 30

7.2. Comparision with Other Modelling Techonologies Most relevant modelling approaches for analysis and design of embedded RT software applications are profiles of the Unified Modeling Language (UML) such as the UML Profile for Schedulability, Performance, and Time (SPT) [30], the executable Unified Modeling Language (xUML) [31], Modeling and Analysis of Real-Time Embedded systems (MARTE) [32], and the Architecture Analysis and Design Language (AADL) [33]. The UML is a high-level description language that provides means for an abstract representation (independently of the execution hardware platform) for systems under study. The AADL provides notation for system representations along with analysis methods based on computation and communication models. The UML profiles and the AADL are meant to connect the software abstraction with the hardware characteristics to deal with quality factors (usually related to non-functional requirements). The IEC-61499 standard and the above modeling languages have similarities and differences. They are all for graphical system representations aligned with structural high-level modeling as well as based on the class-object/datatype-instance construction mechanism for object-oriented analysis and design (including component-based system architectures). Although all these languages provide support for behavioral modeling, only some of them (SPT, xUML, and MARTE) particularly deal with timing issues. The strongest point of IEC 61499 is a way to encapsulate a structure and behavior in the same building element (the FB) that also includes the code to be executed and is part of the overall application. This places the standard in a unique position between conceptual abstraction (general purpose) and physical realization (specific domain) and provides a big picture for structural hierarchy and for behavioral hierarchy as to local and global scheduling. However, the standard does not have mechanisms to model timing specifications to predict determinism, and any IEC-61499 application behavior depend on runtime environment. A further discussion on pros and cons from the IEC-61499 standard for aerospace are available in earlier publications [3,12,13]. Table 3 shows advantages and disadvantages from the modeling approaches discussed above. The aspects evaluated from the modelling approaches are (1) specification of functional/non-functional properties, (2) support for model transformation, (3) type of reconfiguration mode, and (4) model distribution (mapping). Table 3. Comparison of the modeling approaches. Approach

Specification

Transformation

Reconfiguration

Distribution

UML SPT xUML MARTE AADL IEC61499

Functional Non-functional: Time Functional and non-functional Non-functional: Time and alocation Functional and non-functional Functional

Platform-independent Platform-independent/dependent Platform-independent/dependent Platform-independent/dependent Platform-independent/dependent Platform-independent

Static Static Static Static Static Static/dynamic

Local Local Local Local Local/global Local/global

8. Concluding Remarks and Future Work The ongoing improvement and modernization of avionics also bring along a technological evolution for the air-vehicle system architecture. This creates opportunities for research on engineering tools (tentatively, modeling technologies from one domain to another) to tackle the challenge of developing reliable time-critical DAAs. Effective modeling languages, distributed deployment, and execution of models are critical to design dependable avionics systems. A simple end-to-end latency analysis of an IEC61499-modelled DAA has been discussed. The DAA model is based on the IEC 61499 standard (an industrial automation standard). The potential use of such a standard to model a DAA has been shown for a deterministic avionics platform as the modeled DAA is able to achieve desired runtime latency for temporal dependability. The above platform is provided by the combination of the IMA and TTP technologies that provides a fully synchronous execution platform for the DAA to guarantee predictive timing performance by means of temporally deterministic performance.


27 of 30

A case study of a distributed fuel control system of the Airbus A380-800 has been presented as a DAA example. A key driver for deterministic RT behavior has been identified and analyzed as the end-to-end latency between sensors and effectors. It depends on the scheduling of tasks in the control computer (computation) and messages (packets) in the TTP network (communication). Latency analysis and a discussion have been carried out to realize the above latency (including worst- and best-case latencies). Latency analysis results from timing metrics and closed-loop control simulation results have been presented. Experimental outcomes have suggested that an IEC61499-based DFCS model can achieve desired runtime latency for temporal dependability when executed in an IMA-TTP platform. There are two main issues that will drive further investigation on this research. First, one of the issues is to develop an approach to endow the IEC-61499 standard with execution notation to specify how FBs are deployed and executed in a computation and communication platform (based on IMA and TTP or any other that provide fully deterministic execution). This issue is aligned with the concept proposed by the AADL [33] and the xUML [31]. Second, there are further execution situations of FBs that need attention. They are discussed in IEC-61499 publications regarding the parallel execution of FBs, cross-connected data and events, and preemptive FBs [34]. Future research will address the two remaining issues mentioned above. Conflicts of Interest: The author declares no conflict of interest.

Appendix A This appendix shows the FBs that define the main FMMS application. Each sub-application (as defined in Appendix A) is highlighted. The following FB diagram obviously does not include the publisher FBs or subscriber FBs used to split sub-applications from the main FMMS application. Figure A1 shows the FBs and their connections that form the main FMMS application along with the end-to-end latency Aerospace 2018, 4, x FORstudied. PEER REVIEW 27 of 30 ILAcq

FPan INT0 IND

INT

IRSam REQ

REQ

CNF


IO_READER SP

SPI

ILSam

CNF

FACEPLATE 100

INT0 CNF

IN T REQ

SAMPLE_UINT IN

#IL_Addr

ID

FB_REAL_UNIT

RD_1

OUT

IN

Fuel-cockpit-panel sub-application

REQ

0

COLD WARM STOP

CNF

START

EO

EI1 EI1 R

FB_PIDR

E0

MPQue

E_CYCLE DT

True

E_REND

SCAN

t#1ms

MPPI DC

RENDEZVOUS

START

E_RESTART

OUT

Data-concentration sub-application

REQ

MPWri INT REQ

CNF

FB_REAL_UNIT IN

OUT

2. 5 INT0 CNF

IO_WRITER #MP_Addr

ID SD_1

t#250m s t#1s t#0s


XOUT

End-to-end latency


Figure A1. Main FMMS application. Figure A1. Main FMMS application.

Appendix B Table B1 shows the FBs included in each sub-application. The duration of tasks is estimated and assigned longer than the FBs to consider real software blocks potentially required by the FMMS in the A380-800.


28 of 30

Appendix B Table A1 shows the FBs included in each sub-application. The duration of tasks is estimated and assigned longer than the FBs to consider real software blocks potentially required by the FMMS in the A380-800. Table A1. Function Blocks (FBs) of each sub-application. Sub-Application

Data-concentration

Functionality

Function Block (FB)

Acron.

Duration (µs)

ITT sensing

ITT Level Acquirer ITT Level Publisher IEFT Level Acquirer IEFT Level Publisher

ILAcq ILPub IELAcq IELPub

550 200 550 200

Mid pump control

ITT Ref Subscriber ITT Ref Sampler ITT Level Subcriber ITT Level Sampler Mid Pump PID Controller Mid Pump Queuer Mid Pump Publisher IEFT Ref Subscriber

IRSub IRSam ILSub ILSam MPPIDC MPQue MPPub IERSub

200 250 200 250 750 250 200 200

Transfer pump control

IEFT Ref Sampler IEFT Level Subcriber IEFT Level Sampler Transf Pump PID Controller Transfer Pump Queuer Transfer Pump Publisher ITT Ref Subscriber Mid Pump Subscriber

IERSam IELSub IELSam TPPIDC TPQue TPPub IRSub MPSub

250 200 250 750 250 200 200 200

Pilot interface

Fuel Panel Operation Mode Publisher ITT Ref Publisher ITT Level Subcriber IEFT Level Subcriber

FPan OMPub IRPUB ILSub IELSub

450 200 200 200 200

Fuel gauging

Mid Pump Subcriber Mid Pump Writer Transf Pump Subcriber Transf Pump Writer

MPSub MPWri TPSub TPWri

150 50 150 50

Control-command

Fuel-cockpit-panel

Fuel-level-display

References 1.

2. 3.

4. 5. 6.

MIL-STD-1553B in Avionics: Where Data Networking Has Been and Where It’s Going. Available online: http://www.intelligent-aerospace.com/articles/2017/04/mil-std-1553b-in-avionics-where-datanetworking-has-been-and-where-it-s-going.html (accessed on 30 January 2018). Gaska, T.; Watkin, C.; Chen, Y. Integrated Modular Avionics—Past, present, and future. IEEE Aerosp. Electron. Syst. Mag. 2015, 30, 12–23. [CrossRef] Insaurralde, C. Distributed control modeling standard from industrial automation for aerospace. In Proceedings of the 35th Digital Avionics Systems Conference (DASC), Sacramento, CA, USA, 25–29 September 2016. IEC 61499-1, Function Blocks—Part 1: Architecture, 2.0. ed. TC 65/SC 65B. 2012. Available online: https://webstore.iec.ch/publication/5506 (accessed on 7 November 2012). TTTech TTA Group. Time-Triggered Protocol TTP/C High-Level Specification Document; TTTech: Vienna, Austria, 2002. Langton, R.; Clark, C.; Hewitt, M.; Richards, L. Fuel System Design Examples. In Aircraft Fuel Systems, 1st ed.; Aeorspace Series; Moic, I., Seabridge, A., Langton, R., Eds.; John Wiley & Sons Ltd.: Chichester, UK, 2009; pp. 301–315.


7. 8.

9. 10. 11. 12.

13.

14.

15.

16.

17.

18.

19. 20. 21. 22. 23. 24. 25.

26. 27.

29 of 30

Feiler, P.; Hansson, J. Flow Latency Analysis with the Architecture Analysis and Design Language (AADL); Technical Note CMU/SEI-2007-TN-010; Carnegie Mellon: Pittsburgh, PA, USA, 2007. Air Traffic Organization, U.S. Department of Transportation. Handbook for Real-Time Operating Systems Integration and Component Integration Considerations in Integrated Modular Avionics Systems; U.S. Department of Transportation: New Jersey, WA, USA, 2008. Airlines Electronic Engineering Committee. ARINC Specification 653-1—Avionics Application Software Standard Interface; Aeronautical Radio, Inc.: Annapolis, MD, USA, 2003. SAE Aerospace Standard (AS). AS6003 TTP Communication Protocol; SAE Aerospace Standard: Kissimmee, FL, USA, 2011. Vyatkin, V. IEC 61499 as Enabler of Distributed and Intelligent Automation: State-of-the-Art Review. IEEE Trans. Ind. Inform. 2011, 7, 768–781. [CrossRef] Insaurralde, C.C.; Seminario, M.A.; Jimenez, J.F.; Giron-Sierra, J.M. IEC 61499 Model for Avionics Distributed Fuel Systems with Networked Embedded Holonic Controllers. In Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Chez Republic, 20–22 September 2006; pp. 388–396. Insaurralde, C.C.; Seminario, M.A.; Jimenez, J.F.; Giron-Sierra, J.M. FB-Oriented Approach to Model an Aircraft Distributed Control Architecture—Avionics Fuel Systems. In Automation Technology in Practice International; Oldenbourg Industrieverlag: München, Germany, 2008; Issue 1, pp. 33–42. Liu, X.; Cao, C.; Zhao, X.; Sun, J.; Zhu, J. Network performance Analysis of time-triggered Ethernet based on network calculus for DIMA. In Proceedings of the 34th Digital Avionics Systems Conference (DASC), Prague, Czech Republic, 13–17 September 2015. Hamadou, S.; Mullins, J.; Gherbi, A.; Beji, S. A time-triggered constraint-based calculus for avionic systems. In Proceedings of the 18th IEEE International Symposium on Real-Time Distributed Computing Workshops, Auckland, New Zealand, 13–17 April 2015. Hamadou, S.; Mullins, J.; Chareton, C.; Gherbi, A. Specifying avionic embedded systems by denotations of the time-triggered constraint-based calculus. In Proceedings of the 16th IEEE International Conference on Information Reuse and Integration, San Francisco, CA, USA, 13–15 August 2015. Han, Y.; He, F. Design of DIMA scheduling algorithm based on network partition integrating model. In Proceedings of the 33th Digital Avionics Systems Conference (DASC), Colorado Spring, CO, USA, 5–9 October 2014. Lauer, M.; Mullins, J.; Yeddes, M. Cost Optimization Strategy for Iterative Integration of Multi-Critical Functions in IMA and TTEthernet Architecture. In Proceedings of the 37th IEEE Annual Computer Software and Applications Conference Workshops, Kyoto, Japan, 22–26 July 2013. Jakovljevic, M. Synchronous/asynchronous Ethernet networking for mixed criticality systems. In Proceedings of the 28th Digital Avionics Systems Conference (DASC), Orlando, FL, USA, 23–29 October 2009. Jakovljevic, M.; Insaurralde, C.; Ademaj, A. Embedded cloud computing for critical systems. In Proceedings of the 33th Digital Avionics Systems Conference (DASC), Colorado Spring, CO, USA, 5–9 October 2014. Voss, S. Integrated Task and Message Scheduling in Time-Triggered Aeronautic Systems. Ph.D. Thesis, Duisburg-Essen University, Munich, Germany, 2010. Tamas-Selicean, D. Design of Mixed-Criticality Applications on Distributed Real-Time Systems. Ph.D. Thesis, Technical University of Denmark, Kongens Lyngby, Denmark, 2014. Scarlett, J.J.; Brennan, R.W. Evaluating a new communication protocol for real-time distributed control. Robotics Comput. Integr. Manuf. 2011, 27, 627–635. [CrossRef] Young, L.H. Modelling and Synthesis of Safety-Critical Software with IEC61499. Ph.D. Thesis, University of Auckland, Auckland, New Zealand, 2010. Dai, W.; Pang, C.; Vyatkin, V.; Christensen, J.H. Time-stamped event based execution semantics for industrial cyber-physical systems. In Proceedings of the IEEE 13th International Conference on Industrial Informatics (INDIN), Cambridge, UK, 22–24 July 2015; pp. 1263–1268. Hu, M.; Luo, J.; Wang, Y.; Veeravalli, B. Scheduling periodic task graphs for safety-critical time-triggered avionics systems. IEEE Trans. Aerosp. Electron. Syst. 2015, 51, 2294–2304. [CrossRef] The Function Block Development Kit (FBDK). Available online: http://www.holobloc.com/doc/fbdk/ index.htm (accessed on 6 September 2017).


28. 29.

30. 31. 32. 33. 34.

30 of 30

Zoilt, A.; Lewis, R. Modelling Control Systems Using IEC 61499, 2nd ed.; IET Control Engineering Series 95; Institution of Engineering and Technology: Stevenage, Herts, UK, 2014; p. 26. Cervin, A.; Årzén, K.-E.; & Henriksson, D. Control Loop Timing Analysis Using TrueTime and Jitterbug. In Proceedings of the 14th IEEE International Symposium on Computer Aided Control System Design (CACSD), Munich, Germany, 4–6 October 2006. Object Management Group (OMG), UML Profile for Schedulability, Performance, and Time, Version 1.1. Available online: http://www.omg.org/spec/SPTP/About-SPTP/ (accessed on 30 January 2018). Mellor, S.J.; Balcer, M.J. Executable UML: A Foundation for Model-Driven Architecture; Addison-Wesley Professional: Boston, MA, USA, 2002. Object Management Group (OMG). A UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems; Report; Object Management Group: Needham, MA, USA, 2008. Architecture Analysis & Design Language (AADL)—Modeling Language for Safety-Critical Systems. Available online: http://www.aadl.info (accessed on 30 January 2018). Strasser, T.; Zoilt, A.; Christensen, J.H.; Sunder, C. Design and Execution Issues in IEC 61499 Distributed Automation and Control Systems. IEEE Trans. Syst. Man Cybern. Part C Appl. Rev. 2011, 41, 41–51. [CrossRef] © 2018 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

Fully-Deterministic Execution of IEC-61499 Models for ... - MDPI

Fully-Deterministic Execution of IEC-61499 Models for ... - MDPI

Suggest Documents

An IEC61499 Execution Environment for an aJile-based ... - CiteSeerX

Performance Models for Split-execution Computing Systems

Hierarchical, Attentive, Multiple Models for Execution ...

Models for Deterministic Execution of Real-Time Multiprocessor ... - Hal

Rewriting for Symbolic Execution of State Machine Models J Strother ...

Development of BIM Execution Plan for BIM Model ... - MDPI

IEC61499 as an Architectural Framework for Integration of ... - CiteSeerX

GeoSquare: collaborative geoprocessing models' building, execution ...

evaluating a pedagogic innovation: execution models ... - CiteSeerX

An Architecture to Extend the IEC61499 Model for ... - Semantic Scholar

An Execution Framework for MARTE-Based Models

Developing IEC61499 in Industrial Processes ... - wseas.us

An IEC61499-Based Development Approach for Distributed Industrial ...

Market-Driven Symbolic Execution of Models of ... - Semantic Scholar

out-of-order execution and structural equivalence of simulation models

out-of-order execution and structural equivalence of simulation models

Maturity Models for Systems Thinking - MDPI

CodeCloud: A Platform to Enable Execution of Programming Models ...

Algebraic Computational Models of OR-Parallel Execution ... - CiteSeerX

CodeCloud: A Platform to Enable Execution of Programming Models ...

On the Use of Software Models during Software Execution - CiteSeerX

Weaving Definition and Execution Aspects of Process Meta-Models

Refining the Execution of Abstract Actions with Learned Action Models

Decoupled execution of synchronous coordination models via ... - arXiv