European Component Oriented Architecture (ECOA ) Collaboration Programme: Architecture Specification Part 3: Mechanisms

Transcription

1 Eurpean Cmpnent Oriented Architecture (ECOA ) Cllabratin Prgramme: Architecture Specificatin Part 3: Mechanisms BAE Ref N: IAWG-ECOA-TR-007 Dassault Ref N: DGT F Issue: 6 Prepared by BAE Systems (Operatins) Limited and Dassault Aviatin This specificatin is develped by BAE SYSTEMS, Dassault Aviatin, Bull SAS, Thales Systèmes Aérprtés, GE Aviatin Systems Limited, General Dynamics United Kingdm Limited and Lenard MW Ltd and the cpyright is wned by BAE SYSTEMS, Dassault Aviatin, Bull SAS, Thales Systèmes Aérprtés, GE Aviatin Systems Limited, General Dynamics United Kingdm Limited and Lenard MW Ltd. The infrmatin set ut in this dcument is prvided slely n an as is basis and c-develpers f this specificatin make n warranties expressed r implied, including n warranties as t cmpleteness, Nte: This specificatin represents the utput f a research prgramme. Cmpliance with this specificatin shall nt in itself relieve any persn frm any legal bligatins impsed upn them. Prduct develpment shuld rely n the DefStan r BNAE publicatins f the ECOA standard. DGT F/IAWG-ECOA-TR-007 Issue 6 i

2 Cntents 0 Intrductin vi 1 Scpe 1 2 Warning 1 3 Nrmative References 1 4 Definitins 2 5 Abbreviatins 2 6 ECOA Mechanisms 3 7 Interactins Mdule Interactins Mdule Instance Queues Event Event Sent by Prvider Event Received by Prvider Request Respnse Synchrnus Request Asynchrnus Request Respnse Versined Data Versined Data with access cntrl Versined Data withut access cntrl Ntifying Versined Data Trigger Dynamic Trigger Dynamic Trigger Operatins Interactins within Cmpnents Assembly, Cmpnent and Mdule Prperties Persistent Infrmatin PINFO Attributes Private PINFO Public PINFO PINFO rganizatin PINFO API Driver Cmpnents 27 8 Services Overview 29 DGT F/IAWG-ECOA-TR-007 Issue 6 ii

3 8.2 Service Link Behaviur Intrductin Summary f Behaviur Examples 31 9 ECOA System Management Lifecycle Mdule Startup Mdule Run-time Behaviur Mdule Shutdwn Graceful vs fast shutdwn Graceful shutdwn prcedure Fast shutdwn prcedure Health Mnitring Fault Handling Errr Categrizatin Errr Prpagatin and Recvery Actins Applicatin Errrs Prpagatin and Recvery Actins Infrastructure Errrs prpagatin and Recvery Actins Operatins and faults Mdule Cntext Scheduling Scheduling Plicy Activating and nn-activating Mdule Operatins Mdule Operatin Link Behaviur Utilities Inter Platfrm Interactins Cmpsites Use f Cmpsites in Platfrm Integratin 56 Figures Figure 1 ECOA Interactins - Key 4 Figure 2 Event Sent by Prvider 5 Figure 3 Event Received by Prvider 6 Figure 4 Synchrnus Client Request-Respnse 7 Figure 5 Asynchrnus Client Request-Respnse 8 Figure 6 Deferred Respnse Server Request-Respnse 9 DGT F/IAWG-ECOA-TR-007 Issue 6 iii

4 Figure 7 Versined Data Repsitries Single Writer Use Case 11 Figure 8 Versined Data Repsitries Internal + External Writer Use Case 12 Figure 9 Versined Data Repsitries Several External Writers Use Case 13 Figure 10 Versined Data with access cntrl Behaviur 14 Figure 11 Versined Data withut access cntrl Behaviur 16 Figure 12 Ntifying Versined Data Behaviur illustrated with access cntrl 17 Figure 13 Ntifying Versined Data Behaviur illustrated withut access cntrl 18 Figure 14 Trigger Behaviur 19 Figure 15 Dynamic Trigger Behaviur 20 Figure 16 Interactins within Cmpnents Synchrnus Request-Respnse 21 Figure 17 Aspects f PINFO 23 Figure 18 PINFO rganizatin prir t deplyment 24 Figure 19 PINFO API 26 Figure 20 Driver Cmpnent Example Interactin with Bespke APIs 27 Figure 21 Driver Cmpnent Example External Asynchrnus Interactin 28 Figure 22 Service Links 30 Figure 23 Example Assembly Schema 32 Figure 24 Generatin f an Event 32 Figure 25 Cnsumptin f an Event 33 Figure 26 Synchrnus Request-Respnse Operatin 33 Figure 27 Asynchrnus Request-Respnse Operatin 34 Figure 28 Versined Data 34 Figure 29 Mdule Runtime Lifecycle 36 Figure 30 Mdule Run-time Behaviur Startup 38 Figure 31 Mdule Run-time Behaviur Stp 38 Figure 32 Mdule Run-time Behaviur Shutdwn 39 Figure 33 Prpagatin path f nn-fatal applicatin errr 41 Figure 34 Prpagatin path f fatal applicatin errrs 42 Figure 35 Prpagatin path f infrastructure errrs 43 Figure 36 Errr prpagatin path 44 Figure 37 Event faults prpagatin behaviur 45 Figure 38 Request-Respnse faults prpagatin behaviur part 1 46 Figure 39 Request-Respnse faults prpagatin behaviur part 2 47 Figure 40 Versined Data faults prpagatin behaviur 49 Figure 41 Management f Mdule Cntext 51 Figure 42 Interactins between Service Operatins and Mdule Operatins 54 Figure 43 A Cmpsite 56 DGT F/IAWG-ECOA-TR-007 Issue 6 iv

5 Tables Table 1 Behaviur acrss a Service Link 31 Table 2 User and Warm Start Mdule Cntext Vlatility 50 DGT F/IAWG-ECOA-TR-007 Issue 6 v

6 0 Intrductin 0.1 Executive Summary The Eurpean Cmpnent Oriented Architecture (ECOA ) prgramme represents a cncerted effrt t reduce develpment and thrugh-life-csts f the increasingly cmplex, sftware intensive systems within military platfrms. ECOA aims t facilitate rapid system develpment and upgrade t supprt a netwrk f flexible platfrms that can cperate and interact, enabling maximum peratinal effectiveness with minimum resurce cst. ECOA prvides the imprved sftware architectural appraches required t achieve this. The standard is primarily fcussed n supprting the missin system sftware f cmbat air platfrms - bth new build and legacy upgrades - hwever the ECOA slutin is equally applicable t missin system sftware f land, sea and nn-cmbat air platfrms. The ECOA specificatin is dcumented in ten parts, cllectively identified as the Architecture Specificatin. 0.2 Main Intrductin This Architecture Specificatin prvides the specificatin fr creating ECOA -based systems. It describes the standardised prgramming interfaces and data-mdel that allw develpers t prduce ECOA cmpnents and cnstruct ECOA -based systems. It uses terms defined in the Definitins (Architecture Specificatin Part 2). The details f the ther dcuments cmprising the rest f this Architecture Specificatin can be fund in Sectin 3. This dcument is Part 3 f the Architecture Specificatin; it acts as an intrductin t ECOA. The dcument is structured as fllws: Sectin 6 prvides an verview f the mechanisms that are used fr interactins between Mdules in the system. Sectin 7 describes in details the behaviur f the interactins in an ECOA system. Sectin 8 describes Services and Service Link behaviur in an ECOA system. Sectin 9 describes the System Management mechanisms that are prvided by the Infrastructure. Sectin 10 describes the supprt fr scheduling within an ECOA system. Sectin 11 describes Mdule Operatin behaviur. Sectin 12 describes the utilities prvided by the ECOA Sftware Platfrm. Sectin 13 describes hw inter-platfrm cmmunicatin ccurs within an ECOA system. Sectin 14 describes the cncept f a cmpsite (cllectin f Applicatin Sftware Cmpnents). Sectin 15 describes the usage f cmpsites in Platfrm Integratin. DGT F/IAWG-ECOA-TR-007 Issue 6 vi

7 1 Scpe This Architecture Specificatin specifies a unifrm methd fr design, develpment and integratin f sftware systems using a cmpnent riented apprach. 2 Warning This specificatin represents the utput f a research prgramme. Cmpliance with this specificatin shall nt in itself relieve any persn frm any legal bligatins impsed upn them. Prduct develpment shuld rely n the DefStan r BNAE publicatins f the ECOA standard. 3 Nrmative References Architecture Specificatin Part 1 Architecture Specificatin Part 2 Architecture Specificatin Part 3 Architecture Specificatin Part 4 Architecture Specificatin Part 5 Architecture Specificatin Part 6 Architecture Specificatin Part 7 Architecture Specificatin Part 8 Architecture Specificatin Part 9 IAWG-ECOA-TR-001 / DGT Issue 6 Architecture Specificatin Part 1 Cncepts IAWG-ECOA-TR-012 / DGT Issue 6 Architecture Specificatin Part 2 Definitins IAWG-ECOA-TR-007 / DGT Issue 6 Architecture Specificatin Part 3 Mechanisms IAWG-ECOA-TR-010 / DGT Issue 6 Architecture Specificatin Part 4 Sftware Interface IAWG-ECOA-TR-008 / DGT Issue 6 Architecture Specificatin Part 5 High Level Platfrm Requirements IAWG-ECOA-TR-006 / DGT Issue 6 Architecture Specificatin Part 6 ECOA Lgical Interface IAWG-ECOA-TR-011 / DGT Issue 6 Architecture Specificatin Part 7 Metamdel IAWG-ECOA-TR-004 / DGT Issue 6 Architecture Specificatin Part 8 C Language Binding IAWG-ECOA-TR-005 / DGT Issue 6 Architecture Specificatin Part 9 C++ Language Binding DGT F/IAWG-ECOA-TR-007 Issue 6 1

8 Architecture Specificatin Part 10 Architecture Specificatin Part 11 IAWG-ECOA-TR-003 / DGT Issue 6 Architecture Specificatin Part 10 Ada Language Binding IAWG-ECOA-TR-031 / DGT Issue 6 Architecture Specificatin Part 11 High Integrity Ada Language Binding ISO/IEC 8652:1995(E) with COR.1:2000 ISO/IEC 9899:1999(E) ISO/IEC 14882:2003(E) Ada95 Reference Manual Issue 1 Prgramming Languages C Prgramming Languages C++ SPARK_LRM The SPADE Ada Kernel (including RavenSPARK) Issue 7.3 sca-assembly-1.1-spec-cd03 Service Cmpnent Architecture Assembly Mdel Specificatin Versin 1.1 Available at: 4 Definitins Fr the purpse f this standard, the definitins given in Architecture Specificatin Part 2 apply. 5 Abbreviatins API ASC CPU ECOA ELI FIFO ID OS PINFO QS UDP XML XSD Applicatin Prgramming Interface Applicatin Sftware Cmpnent Central Prcessing Unit Eurpean Cmpnent Oriented Architecture. ECOA is a registered trademark. ECOA Lgical Interface First In, First Out Identifier Operating System Persistent Infrmatin Quality f Service User Datagram Prtcl extensible Markup Language XML Schema Definitin DGT F/IAWG-ECOA-TR-007 Issue 6 2

9 6 ECOA Mechanisms The Architecture Specificatin Part 1 defines an architecture which uses Applicatin Sftware Cmpnents and Services. This dcument describes the mechanisms defined by ECOA and the way that Cmpnents interact. Additinally, it describes the behaviur f ther aspects f an ECOA system including management and utility functins alng with hw different ECOA Sftware Platfrms interact. Sme f the mechanisms are described in detail within this dcument, whereas thers are nly discussed at a high level, as they are cvered in greater depth in ther dcuments. Where this is the case a reference will be prvided. The intended audience fr this reference manual is: Cmpnent Develpers: T understand the mechanisms available fr develping applicatins ECOA Platfrm Develpers: T understand the behaviur an ECOA Platfrm is required t prvide fr a given mechanism This dcument describes the mechanisms available t an Applicatin Sftware Cmpnent, but it is the Architecture Specificatin Part 4 which prvides the abstract API fr implementing the mechanisms described herein. 7 Interactins 7.1 Mdule Interactins Interactins between Mdule Instances in an ECOA system rely n three primary mechanisms: Events Request-Respnse Versined Data (with r withut access cntrl) The interactins between Mdule Instances can ccur within a single Applicatin Sftware Cmpnent, r between Mdule Instances f different Applicatin Sftware Cmpnents, as a cnsequence f their Services. Fr detail n the behaviurs, see sectins 8.2 and 11 respectively. In additin t the abve mechanisms, Operatins exist fr Infrastructure Services t allw the management f the runtime lifecycle, prperties, lgging, faults, time services, service availability, persistent infrmatin and cntext management. The fllwing sectins include numerus figures, which illustrate the interactins within an ECOA system and prvide visual clarity. The key shwn in Figure 1 ffers guidance n the cluring and symblgy used thrughut these sectins. DGT F/IAWG-ECOA-TR-007 Issue 6 3

10 Figure 1 ECOA Interactins - Key Nte that the Cmpnent develper is nly respnsible fr implementing the functinality within the Mdule Instance. The ther infrastructure bjects shwn are the respnsibility f the ECOA Platfrm Develper and cmprise the Platfrm Integratin Cde (e.g. Trigger Instances, Mdule Instance Queues, Versined Data repsitries, Service Links etc.). 7.2 Mdule Instance Queues Mdule run-time behaviur is dependent upn the Mdule Runtime Lifecycle state (see 9.1). A set f predefined Mdule Operatins called Mdule Lifecycle Operatins exist t allw the Cntainer t infrm the Mdule f changes t its Lifecycle. Mdule Lifecycle Operatins are handled in any state (t enable the Lifecycle f a Mdule Instance t be managed), whereas nrmal Mdule Operatins are nly handled in the RUNNING state. Mdule Operatin calls are placed in the Mdule Instance Queue, and the crrespnding entry-pint fr the Mdule Instance is invked when the Operatin reaches the frnt f the queue (if the Operatin is specified as an activating Operatin, see sectin 10.2 fr further detail n activating and nn-activating Operatins). Mdule Operatin calls ther than Mdule Lifecycle Operatins are nly queued if the Mdule Instance is in the RUNNING state and if, fr a particular Mdule Operatin, the maximum number f waiting peratin calls des nt reach the value given by the attribute fifsize defined n the receiving part f the assciated OperatinLink. If the Mdule Instance is nt in the RUNNING state Mdule Operatins are discarded. Whenever a request is discarded by the ECOA Infrastructure, the ECOA Infrastructure returns with «n respnse» errr cde t the Client Mdule as far as is pssible. Nte: it is recmmended that a timeut is specified n the Client side. This is due t the fact that sme failures cannt be detected and a n respnse errr may never be received. Fr example a netwrk failure may prevent a remte ECOA Infrastructure n the server side frm infrming the client that it has discarded the request, r the request itself may never reach the server. 7.3 Event The Event mechanism is used fr ne-way asynchrnus push-style cmmunicatin between Mdule Instances and may ptinally carry typed data. DGT F/IAWG-ECOA-TR-007 Issue 6 4

11 When Events are used t implement a Service Operatin, a Mdule Instance may be either the sender r receiver f an Event irrespective f whether it is designated as the Prvider r Requirer f the Service. Events are wait-free and ne-way : the Sender is never blcked and des nt receive any feedback frm the Receiver. Events arriving n a full Receiver queue are lst, and the fault is reprted t the faultmanagement Infrastructure. There may be multiple receivers f an Event within a Cmpnent (e.g. ther Mdule Instances r Service Instances), in which case instances f the Event are bradcast t all receivers. If an Event arrives at a Mdule Instance that is nt in the RUNNING state, the Event is discarded silently Event Sent by Prvider In the case f an Event sent by Prvider, the prviding Applicatin Sftware Cmpnent initiates the sending. This behaviur is shwn in Figure 2. Figure 2 Event Sent by Prvider Figure 2 shws, at pint 1, a Mdule Operatin being invked n the sender Mdule Instance (f the Prviding Cmpnent instance) as a result f sme ther activity. During this executin, the Mdule Instance perfrms an Event Send Cntainer Operatin (Sent by Prvider) at pint 2. The Send peratin returns immediately, allwing the Sender Mdule Instance t cntinue its executin. The Event will be queued n the Receiver Mdule Instance Queue, (f the Requiring Cmpnent instance) shwn at pint 3. The apprpriate Event Received Mdule Operatin will then be invked n the Receiver Mdule Instance when the queue is prcessed and the Event reaches the frnt f the queue, at pint Event Received by Prvider In the case f an Event received by Prvider, the requiring Cmpnent initiates the sending. This behaviur is shwn in Figure 3. DGT F/IAWG-ECOA-TR-007 Issue 6 5

12 Figure 3 Event Received by Prvider Figure 3 shws, at pint 1, a Mdule Operatin being invked n the Sender Mdule Instance (f the requiring Cmpnent instance) as a result f sme ther activity. During this executin, the Mdule Instance perfrms an Event Send Cntainer Operatin (sent by requirer) at pint 2. The Event Send peratin returns immediately, allwing the initiating Mdule Instance t cntinue its executin. The Event will be queued n the Receiver Mdule Instance Queue (f the Prviding Cmpnent instance) shwn at pint 3. The Event Received Mdule Operatin will then be invked n the Receiver Mdule Instance when the queue is prcessed and the Event reaches the frnt f the queue, at pint Request Respnse The Request-Respnse mechanism is a tw-way cmmunicatin between Mdule Instances. The calling Mdule Instance Requests an peratin and the called Mdule Instance prvides a Respnse. The Requesting Mdule Instance (sender f the Request) is named the Client, and the prviding Mdule Instance (sender f the Respnse) is named the Server. A Request may carry data ( in parameters) and the Respnse may als carry data ( ut parameters). All parameters are named and typed. There are tw mechanisms fr Request peratins which prvide synchrnus and asynchrnus behaviur at the Client and ne mechanism fr Respnse peratins at the Server. The details f these are described in the fllwing sectins. Fr each Request-Respnse, the set f pssible Clients and Server is identified at design time, as is whether the Client uses the synchrnus r asynchrnus mechanism. Fr a given Client, there is nly ne Server. A Respnse frm a Server is nly sent t the particular Client that has issued the Request. The client Cntainer instance will implement a timeut (if defined at cmpnent implementatin level) in rder t unblck the Client f a Synchrnus Request-Respnse r t infrm the Client f an Asynchrnus Request Respnse if n Respnse is received within the given timeut. The value f the timeut is defined DGT F/IAWG-ECOA-TR-007 Issue 6 6

13 at cmpnent implementatin level; this can be related t QS maximum respnse time in the case f service peratins. If the Respnse arrives after the timeut, the Respnse is discarded by the cntainer and the fault is handled by the fault management. If the timeut is set t less than zer, it is cnsidered as infinite; the Client f a Synchrnus Request-Respnse remains blcked indefinitely if it never receives a Respnse. A Request may fail if the Server is nt available (e.g. it is nt RUNNING, the remte platfrm is DOWN, netwrk errr). When such a failure can be detected by the Infrastructure, it returns with «n respnse» errr cde t the client, and reprts the fault t the fault-management Infrastructure. Where failures cannt be detected by the infrastructure, the client may use the timeut t avid being blcked indefinitely Synchrnus Request In the case f a Synchrnus Request, the Client Mdule Instance is blcked until the Respnse is received, as shwn in Figure 4. Figure 4 Synchrnus Client Request-Respnse Figure 4 shws, at pint 1, a Mdule Operatin being invked n the Client Mdule as a result f sme ther activity. During this executin, the Mdule Instance perfrms a Synchrnus Request peratin at pint 2. At the pint the Request is made, the Client Mdule Instance becmes blcked. When blcked, the Client Mdule Instance des nt handle any ther incming Mdule Operatin. Frm a mdule lifecycle pint f view, this blcking situatin is cnsidered as a sub-state f the RUNNING state (see 9.1). The Request peratin is cnnected via a Service Link t the Server Mdule Instance, whereby the Request peratin is queued in the Server Mdule Instance Queue, at pint 3. The Request is accepted by the Server Mdule Instance as lng as it has enugh resurces t handle the Respnse and it is in the RUNNING state. If nt, the Request is discarded and a «n respnse» errr cde is returned t the client. The Request peratin will be invked n the Server Mdule Instance at pint 4, which, in this example, will send the Respnse at pint 5 just befre cmpleting the Request peratin. Once the Respnse is received by the Client Mdule Instance, it will becme unblcked and can cntinue its executin at pint 6. DGT F/IAWG-ECOA-TR-007 Issue 6 7

14 7.4.2 Asynchrnus Request In the case f an Asynchrnus Request, the Client is released as sn as the Request has been sent and may cntinue t execute ther functinality. The Respnse results in the call f an peratin n the Requesting Mdule Instance, as shwn in Figure 5. Figure 5 Asynchrnus Client Request-Respnse Figure 5 shws, at pint 1, a Mdule Operatin being invked n the Client Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance perfrms an Asynchrnus Request peratin at pint 2. At the pint the Request is made, the Client Mdule Instance des NOT blck meaning it can finish its executin f the invked peratin. The Request peratin is cnnected via a Service Link t the Server Mdule Instance, whereby the Request peratin is queued in the Server Mdule Instance Queue, at pint 3. The Request is accepted by the Server Mdule Instance as lng as it has enugh resurces t handle the Respnse and it is in the RUNNING state. If nt, the Request is discarded and a «n respnse» errr cde is returned t the client. The Request peratin will be invked n the Server Mdule Instance at pint 4, which, in this example, will send the Respnse at pint 5 just befre cmpleting the Request peratin. The Respnse will then be placed in the Client Mdule Instance Queue at pint 6 as lng as it is in the RUNNING state, and the Respnse call-back peratin will be invked n the Client Mdule Instance at pint Respnse The Server decides when it replies t the Client. It can be dne in the same blck f functinality assciated t the Request (see and 7.4.2) r the Server may defer the prvisin f the Respnse e.g. where it needs t invke a Request-Respnse Service in rder t prvide the Respnse. In the secnd case the Server may cntinue t execute ther functinality befre prviding the Respnse, as shwn in Figure 6. DGT F/IAWG-ECOA-TR-007 Issue 6 8

15 Figure 6 Deferred Respnse Server Request-Respnse Figure 6 shws, at pint 1, a Mdule Operatin being invked n the Client Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance perfrms, in this example, a Synchrnus Request peratin at pint 2. At the pint the Request is made, the Client Mdule Instance becmes blcked. The Request peratin is cnnected via a Service Link t the Server Mdule Instance, wherein the Request peratin is queued in the Server Mdule Instance Queue, at pint 3. The Request is accepted by the Server Mdule Instance as lng as it has enugh resurces t handle the Respnse. If nt, the Request is discarded. The Request peratin will be invked n the Server Mdule Instance at pint 4. The Server may, by design, use the Respnse Cntainer Operatin t send the respnse at sme later time. Fr example, in rder t cmpute the Respnse, it may be necessary t invke a further Asynchrnus Request peratin, meaning the riginal Respnse cannt be cmputed until receipt f this Respnse ccurs. Pint 5, shws anther Mdule Operatin invked n the Mdule Instance, during this executin, at pint 6, the Respnse Cntainer Operatin is called t send the Respnse back t the Client. Once the Respnse is received by the Client Mdule Instance at pint 7, it will becme unblcked and can cntinue its executin. 7.5 Versined Data The Versined Data mechanism allws Mdule Instances t share typed data. A reading Mdule Instance is named a Reader, and a writing Mdule Instance is named the Writer. Fr each Mdule Operatin Link that uses this type f interactin, the Versined Data mechanism can be cnfigured t perate with r withut access cntrl. With access cntrl, the ECOA Infrastructure ensures a cncurrency-safe read-write paradigm between Mdule Instances by making a lcal cpy f the data when a reader r a writer accesses it. DGT F/IAWG-ECOA-TR-007 Issue 6 9

16 Withut access cntrl, the lcal data repsitry is accessed directly by all Mdule Instances. Therefre, cncurrency must be managed at applicatin level by the Cmpnent Supplier. Nte: Versined Data withut access cntrl may be used fr imprving the perfrmance f ASCs in which large datasets are shared between several Mdule Instances. Versined Data withut access cntrl may be selected n a Mdule Operatin Link nly if all Readers and Writers cnnected ver this link are Mdule Instances f the same ASC Instance and are deplyed within the same Prtectin Dmain. This is the cnditin fr the ECOA Infrastructure t implement a single Versined Data repsitry withut lcal cpies. Any Versined Data ver Service Links must be implemented with access cntrl. Nte: Platfrm Tling may check that this cnditin is met when parsing ECOA XMLs prir t Platfrm Integratin Cde generatin. Access cntrl is enabled by default fr each Mdule Operatin Link that uses the Versined Data mechanism, unless explicitly disabled by the Cmpnent Supplier. The details f the Versined Data mechanism with and withut access cntrl are described in the fllwing sectins Versined Data with access cntrl In the case f Versined Data with access cntrl, the Writer can request a lcal cpy f the data and subsequently cmmit r cancel any changes made. This write actin is atmic. It means that the data is written entirely r nt at all. This write peratin is independent f any ther updates t the data-set. When a Versined Data has been written by a Mdule Instance, the ECOA Infrastructure makes it available acrss the ECOA System t any reader Mdule Instance, accrding t the Assembly Schema and accrding t Cmpnent Implementatins. A Reader can als request a lcal cpy f the data, which will be the latest data value(s) at the time f the read request. This lcal cpy will nt be affected by any subsequent changes t the data-set (i.e. by a Writer updating the data-set). Nte that althugh it is pssible fr the Reader t mdify its lcal cpy f the data, it is nt able t update the glbal data-set. The ECOA Infrastructure prvides reader Mdule Instances with a stamp assciated with the receptin f a versined data. This stamp is available within the Versined Data handle. It allws a given reader Mdule Instance t knw if the data has been published (since an arbitrary previus access) r nt. The ECOA Infrastructure hsting a reader Mdule Instance is respnsible fr updating the stamp f the Versined Data. The behavir f the versined data stamp is the fllwing and it is up t the platfrm supplier t chse hw t manage the stamp value accrdingly: The stamp value is 0 when the return status f a read peratin is nt OK. Fr any given reader, each time the data value is updated lcally fr that reader as a cnsequence f a publish actin by a writer, the stamp value shall be different frm the N previus values, N being at least equal t This allws being rbust t N updates f the data since it was last read by the reader. The stamp may wrap arund when reaching max value. Nte 1: the cnsequence is that, frm the reader pint f view, the stamp may nt necessarily be perceived as increasing (it culd g backwards), nr changed by increment f 1 r fixed increments. This behavir shuld be taken int accunt by the mdule applicatin cde. DGT F/IAWG-ECOA-TR-007 Issue 6 10

17 Nte 2: the fact that the stamp is incremented n reader side implies that, fr a given versined data, different reader Mdule Instances may get different stamp values when reading the data, because f asynchrnus distributin f the data acrss the ECOA System (especially with regard t distributin ver ELI). Thereby, stamp values shuld nt be cmpared between different readers. Writers and Readers have t specify the beginning and the end f each (read r write) access t the data. The mechanism is wait-free : n Writer r Reader is blcked waiting fr anther Writer r Reader t release the data r waiting fr the underlying synchrnisatin mechanism t update the lcal data-set. The ECOA Infrastructure implements Versined Data repsitries with respect t the Assembly Schema and Cmpnent Implementatins which define data links between Readers and Writers. It is pssible fr multiple instances f the same Versined Data repsitry t exist in an ECOA system e.g. where the Readers are deplyed n different Cmputing Ndes. As illustrated by Figure 7, Figure 8 and Figure 9 belw, a lcal Versined Data repsitry has t be implemented fr an ASC as sn as there are bth internal and external Writers f the Data, r as sn as there is mre than ne external Writer f the Data (frm the viewpint f that ASC). Figure 7 Versined Data Repsitries Single Writer Use Case Figure 7 illustrates a use case f a single external Writer f the Data and n internal Writer (frm the viewpint f ASCs A and D ). In this case, the ECOA Infrastructure may implement a single repsitry fr these three ASCs, depending n ptimisatins allwed by ASCs deplyment nt Cmputing Ndes. DGT F/IAWG-ECOA-TR-007 Issue 6 11

18 Figure 8 Versined Data Repsitries Internal + External Writer Use Case Figure 8 illustrates a use case f simultaneus external and internal Writers f the Data (frm the viewpint f ASC A ). In this case, the ECOA Infrastructure shuld implement a separate Versined Data repsitry fr ASC A. It may implement a single repsitry fr ASCs C and D, depending n ptimisatins allwed by ASCs deplyment nt Cmputing Ndes. The reasn fr this is that Mdule Instance D.M1 and C.M1 must nt have visibility f any data written by Mdule Instance A.M2 due t the limitatins impsed by the data flws accrding t the Wires and Data Links. Mdule Instance A.M1 wuld still have visibility f data written by Mdule Instance C.M1. DGT F/IAWG-ECOA-TR-007 Issue 6 12

19 Figure 9 Versined Data Repsitries Several External Writers Use Case Figure 9 illustrates a use case f multiple external Writers f the Data (frm the viewpint f ASC D ). In this case, the ECOA Infrastructure implements different Versined Data repsitries fr ASCs A, B and C. It may implement a single repsitry fr ASC C and ASC D, depending n ptimisatins allwed by ASCs deplyment nt Cmputing Ndes. Mdule Instance D.M1 must nt have visibility f any data written by Mdule Instance B.M1 due t the limitatins impsed by the data flws accrding t the Wires and Data Links. Similarly, Mdule Instances B.M1 and C.M1 must nt have visibility f any data written by each ther. When the access t the data begins: The Reader always gets the latest cpy f data available lcally, The Writer either gets the latest cpy f data available lcally ( Read+Write mde) r gets an uninitialized cpy ( Write nly mde), accrding t a Metamdel attribute. The default mde is Read+Write. NOTE: Write Only mde avids cpying the latest data value fr Writers which d nt need t read it, thereby imprving perfrmance within the ECOA Infrastructure. DGT F/IAWG-ECOA-TR-007 Issue 6 13

20 As stated previusly, the stamp enables the caller t determine if the data has been refreshed since the last read peratin. The Reader gets an errr if data has never been received r initialized. Nte that at the mment the data is requested, there is n guarantee that it is synchrnised with the latest update, particularly in a distributed system. Any cpy that is made t enable a read r write access is islated, in that it will nt be changed by any cncurrent mdificatins f the data, and lcal changes will nt cause the Versined Data repsitry t be updated. The lcal cpy is discarded after the read r write has been cmpleted. A read access ends when it is released A write access ends with tw pssible alternatives: publish mdificatins made by the Writer are published t the Versined Data repsitry cancel the mdified lcal cpy f the data is discarded withut making any mdificatins t the Versined Data repsitry. Data publicatins are atmic; simultaneus publicatins f the same dataset cannt crrupt the data cntent. This behaviur may require supprt frm the Infrastructure. An ptinal attribute (maxversins) may be set in the Cmpnent Implementatin as an attribute f the data read/write peratin t specify the maximum number f cncurrent read r write accesses that may ccur. The number f cncurrent read r write accesses is incremented each time the ECOA Infrastructure grants access t a Mdule Instance after that Mdule Instance made a read r write access request. The number f cncurrent read r write accesses is decremented each time a Mdule Instance releases a read access r publishes/cancels a write access. The number f cncurrent read r write accesses cannt exceed the maxversins attribute value. The default is ne access per peratin e.g. a Read must be released befre the next Read starts. A read r write access request may fail if a new lcal cpy f the data cannt be created. In this case, a null Data Handle is returned, the Client is ntified f the failure f the call, and the fault reprted t the fault-management Infrastructure. Figure 10 Versined Data with access cntrl Behaviur DGT F/IAWG-ECOA-TR-007 Issue 6 14

21 Figure 10 shws, at pint 1, a Mdule Operatin being invked n the Writer Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance perfrms a publish Cntainer Operatin at pint 2. The data is written t the Cmpnent instance lcal cpy f the repsitry at pint 3. The Infrastructure is then respnsible fr cpying the data t any requiring Cmpnents (which may nt be immediate depending upn the implementatin f the Infrastructure) at pint 4 and pint 5 respectively. Als nte that the Infrastructure may ptimise this database management such that the lcal cpies are ne in the same where the cmpnents are deplyed in the same prtectin dmain. Independently, f the Writer, the Reader Mdule Instance can read frm the Versined Data repsitry. Pint 6 shws a Mdule Operatin being invked n the Reader Mdule Instance by sme means (e.g. an Event Received). During this executin, the Mdule Instance perfrms a read Cntainer Operatin at pint Versined Data withut access cntrl In the case f Versined Data withut access cntrl, the ECOA Infrastructure des nt make any lcal cpies f the data when a Reader r a Writer accesses it. Instead, the actual data repsitry address is passed by the ECOA Infrastructure t all Readers and Writers invlved in the crrespnding Mdule Operatin Link. Therefre, it is the applicatin respnsibility t manage/synchrnise/crdinate accesses t the repsitry. The behaviur f the ECOA Infrastructure is the fllwing when access cntrl is disabled: The versined data stamp is updated as a cnsequence f a publish actin by a writer, The number f cncurrent read r write accesses is incremented r decremented depending n read r write access requests and accrding t read r write access releases by Mdule Instances, althugh there are n lcal cpies being created r deleted by the ECOA Infrastructure upn these actins, The number f cncurrent read r write accesses cannt exceed the maxversins attribute value, A publish r cancel actin by a Writer has n effect n the repsitry data as any changes made t the data wuld have already been dne directly, hwever the number f cncurrent write accesses will be decremented/ The ECOA Infrastructure cannt prevent a Reader frm being able t write in the repsitry nce the actual data repsitry address has been prvided. DGT F/IAWG-ECOA-TR-007 Issue 6 15

22 Figure 11 Versined Data withut access cntrl Behaviur Figure 11 shws, at pint 1, a Mdule Operatin being invked n the Writer Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance updates the data repsitry at pint 2. N lcal cpy is made by the ECOA Infrastructure fr this write peratin. Pint 3 shws a Mdule Operatin being invked n the Reader Mdule Instance by sme means (e.g. an Event Received). During this executin, the Mdule Instance perfrms a read Cntainer Operatin at pint 4 thrugh which it accesses the data repsitry directly withut a lcal cpy being made by the ECOA Infrastructure. Figure 11 illustrates that functinal crdinatin between Mdule Instances must be implemented by the Cmpnent Supplier in rder t avid cnflicting accesses t the repsitry Ntifying Versined Data Versined Data Readers can als specify an ptinal attribute (ntifying) t receive a ntificatin f any updates t Versined Data. This behaviur is achieved by queuing a ntificatin Event n the Reader Mdule Instance. This behaviur applies t Versined Data with r withut access cntrl. DGT F/IAWG-ECOA-TR-007 Issue 6 16

23 Figure 12 Ntifying Versined Data Behaviur illustrated with access cntrl Figure 12 shws an example f Ntifying Versined Data with access cntrl. At pint 1, a Mdule Operatin is invked n the Writer Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance perfrms a publish Cntainer Operatin at pint 2. The data is written t the Cmpnent instance lcal cpy f the repsitry at pint 3. The Infrastructure is then respnsible fr cpying the data t any requiring Cmpnents (which may nt be immediate depending upn the implementatin f the Infrastructure) at pint 4 and pint 5 respectively. When the requiring Cmpnent receives the updated data (and as the Reader Mdule Instance has defined the peratin t be ntifying) a ntificatin Event is generated at pint 6 which is queued n the Reader Mdule Instance Queue at pint 7 as lng as it is in the RUNNING state. This invkes the ntificatin Mdule Operatin. The Mdule Instance may then use standard Cntainer Operatins fr getting a read-nly cpy f the latest data value, as detailed in sectin Nte: the latest data value at the time f the read request may be different frm the data value at the time f the ntificatin. DGT F/IAWG-ECOA-TR-007 Issue 6 17

24 Figure 13 Ntifying Versined Data Behaviur illustrated withut access cntrl Figure 15 shws an example f Ntifying Versined Data withut access cntrl. At pint 1, a Mdule Operatin is invked n the Writer Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance updates the data repsitry and perfrms a publish Cntainer Operatin at pint 2. N lcal cpy is made by the ECOA Infrastructure fr this write peratin. As a result f the publish Cntainer Operatin perfrmed by the Writer Mdule Instance, a ntificatin Event is generated at pint 3 which is queued n the Reader Mdule Instance Queue at pint 4 as lng as it is in the RUNNING state. This invkes the ntificatin Mdule Operatin. The Mdule Instance may then use standard Cntainer Operatins fr accessing the data repsitry directly withut a lcal cpy being made by the ECOA Infrastructure, as detailed in sectin Trigger Triggers generate peridic Events which can be used t invke sme functinality prvided by a Mdule Instance r set f Mdule Instances. The Trigger can generate Events which are queued t Mdule Instances within the same Applicatin Sftware Cmpnent and/r generate Events which are queued t Mdule Instances in different Applicatin Sftware Cmpnents via a Service e.g. where a single central Trigger is used t crdinate the executin f functinality f multiple Cmpnents, in the manner f a central clck. The Trigger behaviur fr the case f generating events within a same Cmpnent is shwn in Figure 14. DGT F/IAWG-ECOA-TR-007 Issue 6 18

25 Figure 14 Trigger Behaviur Figure 14 shws, at pint 1, the Trigger Instance sending an Event t the Receiver Mdule Instance Queue. This causes the Mdule Operatin cnnected t the Trigger t be invked n the Receiver Mdule Instance at pint 2. The Trigger Instance will generate the Event at a peridic interval as defined by the Cmpnent implementer. The first Event will be generated ne perid after the Trigger Instance has been started by the ECOA Infrastructure, i.e. ne perid after its lifecycle state has becme RUNNING. The Trigger Instance is prvided by the underlying Infrastructure t generate an Event at a set time interval. The Trigger Instance exhibits a sub-set f the Mdule interface, t enable the ECOA Infrastructure t cntrl the Mdule Lifecycle f the Trigger. NOTE: the Trigger can be cnnected t ne r mre Mdule Operatins and/r Service Operatins. Each peratin link may specify a different trigger perid, s a single trigger may generate events at different perids. 7.7 Dynamic Trigger A Dynamic Trigger sends an Event after a given delay (knwn as the ut Event) frm the receipt f an input Event (knwn as the in Event). The in Event specifies the delay in the frm f the expiry time at which the ut Event shall be sent. A Dynamic Trigger may als receive a reset Event, which will purge all unexpired delays. It is pssible fr multiple Mdule Instances t: Send in and reset Events t the same Dynamic Trigger. Receive the same ut Event. As with the peridic Trigger, the Dynamic Trigger can generate Events which are queued t Mdule Instances within the same Applicatin Sftware Cmpnent and/r generate Events which are queued t Mdule Instances in different Applicatin Sftware Cmpnents via a Service. Multiple ccurrences f the in Event may be prcessed such that a number f delays are waiting t expire. A reset Event is used t purge all currently active delays. The first parameter f a Dynamic Trigger is the expiry time. The remaining parameters can be f any ECOA type r type derived frm ECOA types. DGT F/IAWG-ECOA-TR-007 Issue 6 19

26 The Mdule Instance calculates the expiry time parameter f the in Event by summing the intended delay and the current abslute system time btained by invking the get_abslute_system_time API. The ut Event is generated with exactly the same parameters as the in Event, except that the expiry time parameter is mitted. The ut Event is sent at the specified expiry time, except if the expiry time is already in the past when the Dynamic Trigger prcesses the in Event. In such failure case, the ut Event is sent immediately and the ECOA Infrastructure raises an Errr t the ECOA Fault Handler. Figure 15 Dynamic Trigger Behaviur Figure 15 shws, at pint 1, a Mdule Operatin being invked n a Mdule Instance as a result f sme ther activity. During this executin, the Mdule Instance perfrms, at pint 2, a Cntainer Operatin t request the Dynamic Trigger Instance t send a Trigger Event after a given perid (in Event) specified via the expirytime parameter. The in Event is queued in the Dynamic Trigger Instance Queue, at pint 3, therwise if the queue is full, the event is discarded and an errr raised t the Fault Handler. The queue is prcessed by the Dynamic Trigger, and if the maximum number f cncurrent delays has been reached, the delay is discarded and an errr raised t the Fault Handler, therwise the delay is started. After the delay time has expired (i.e. when the current time becmes equal t r greater than the expiry time), the Dynamic Trigger Instance will generate an ut Event t the Receiver Mdule Instance Queue, shwn at pint 4. The Dynamic Trigger Instance exhibits a sub-set f the Mdule interface, t enable the ECOA Infrastructure t cntrl the Mdule Lifecycle f the Dynamic Trigger Dynamic Trigger Operatins The Dynamic Trigger can be cnsidered as a Mdule whse peratins are: EventReceived in On receptin, the Dynamic Trigger sets the trigger fr the expirytime received in the in Event Parameters: expirytime : expressed as Abslute System Time and typed by ECOA:glbal_time (secnds, nansecnds) p1, p2, etc: user defined parameter based n ECOA types EventSent ut DGT F/IAWG-ECOA-TR-007 Issue 6 20

27 The Dynamic Trigger sends an ut Event at the expiry time received in the in Event. Parameters: p1, p2, etc: are identical (number, types and psitin identical t thse f the in Event) EventReceived reset On receptin, the Dynamic Trigger cancels the trigger settings fr all "in" Events already previusly received and nt yet expired. The transmitted Events in and ut can have several ther parameters (p1, p2, etc.): These parameters are sent unchanged by the Dynamic Trigger. The number f parameters and their types are defined in the Cmpnent implementatin mdel at instance definitin level. 7.8 Interactins within Cmpnents Althugh the majrity f examples shwn in the preceding sectins display interactins between Mdule Instances in multiple Cmpnents (using Services), the exact same interactins can ccur within a Cmpnent bundary (Mdule t Mdule cmmunicatins). Figure 16 Interactins within Cmpnents Synchrnus Request-Respnse Figure 16 shws the interactins f a Synchrnus Request Respnse peratin between tw Mdule Instances within a Cmpnent. At pint 1, a Mdule Operatin is invked n the Client Mdule Instance frm a Service Operatin. During this executin, the Mdule Instance perfrms a Synchrnus Request peratin at pint 2. At the pint the Request is made, the Client Mdule Instance becmes blcked. The Request peratin is cnnected t anther Mdule Instance within the Cmpnent. The Request peratin is queued in the Server Mdule Instance Queue, at pint 3. The Request peratin will be invked n the Server Mdule Instance at pint 4, which can pefrm any prcessing required in rder t prduce the Respnse. DGT F/IAWG-ECOA-TR-007 Issue 6 21

28 In this example, at pint 4, the Mdule Instance invkes a Cntainer Operatin t perfrm an Event Send. The Server Mdule Instance sends the Respnse at pint 5 just befre the Mdule Operatin cmpletes and returns cntrl t the Cntainer. Once the Respnse is received by the Client Mdule Instance, it will becme unblcked and can cntinue its executin at pint Assembly, Cmpnent and Mdule Prperties Cmpnents may be instantiated multiple times within a system. Cmpnent Prperties prvide a means t tailr the behaviur f a Cmpnent Instance. A Cmpnent Prperty is declared as part f the Cmpnent Definitin. Within the Assembly Schema the Cmpnent Instance Prperty Values are assigned fr each Cmpnent Instance. These values are assigned at design time and cannt be changed during executin. A Cmpnent Instance Prperty Value may either be a literal value r a reference t an Assembly Prperty Value. An Assembly Prperty Value is a prperty which is accessible by all Cmpnents within the Assembly. As part f a Cmpnent Implementatin a Mdule Type can have Mdule Prperties declared, which can then be used t tailr different behaviur fr each Mdule Instance. Fr each Mdule Instance, a Mdule Prperty can either reference a Cmpnent Prperty, r be assigned a value at Cmpnent Implementatin time (design time) which cannt be changed during executin. Nte that in rder fr Cmpnent Prperties t be accessed; a Mdule Prperty must be created t reference the Cmpnent Prperty. Mdule Instances can then access Mdule Prperties, and cnsequently Cmpnent Prperties if referenced, via the Cntainer Interface at run-time. The Architecture Specificatin Part 4 cntains mre detail regarding Prperties Persistent Infrmatin Persistent infrmatin is brken dwn int tw main categries related t the extent f its accessibility as fllws: Private PINFO is data accessible by Mdule Instances within the same ASC Instance. Public PINFO is data accessible by any Mdule Instance in the Assembly Schema. PINFO is Read-Only. PINFO can be referenced (i.e. accessed) by multiple Mdule Instances. Figure 17 illustrates the aspects f PINFO and hw they are being declared in an ECOA system. DGT F/IAWG-ECOA-TR-007 Issue 6 22

29 Figure 17 Aspects f PINFO PINFO Attributes Private and Public PINFO have the fllwing attributes assciated with them: PINFO name: This is the name used at Mdule level fr accessing the PINFO. It is NOT the filename assciated t the PINFO. Filename Assciatin: (Path and filename) This is where the file cntaining PINFO data is stred prir t deplyment n the target ECOA Platfrm. Declaratin f PINFO is bunded by the fllwing rules: PINFO Filename Assciatin is declared as a string: The maximum length f that string is 256 characters, The PINFO path and filename declaratin can use alphanumeric characters in additin t the fllwing special characters: "_", ".", "/" The PINFO name declaratin can use alphanumeric characters in additin t the fllwing special character: _ PINFO Filename Assciatin is nt case sensitive Private PINFO A Filename Assciatin can be assciated with mre than ne Private PINFO, amng all Mdule Instances f a given Cmpnent Implementatin. Private PINFO are stred in 4-CmpnentImplementatins/<Cmpnent Implementatin Name>/Pinf directry, and their Filename Assciatin is declared as a relative path t that directry (sub-directries are allwed). NOTE: This fllws the interim data rganisatin structure as defined in Architecture Specificatin Part 7. DGT F/IAWG-ECOA-TR-007 Issue 6 23

30 Public PINFO Public PINFO are stred in 5-Integratin/Pinf directry, and their Filename Assciatin is declared as a relative path t that directry (sub-directries are allwed). NOTE: This fllws the interim data rganisatin structure as defined in Architecture Specificatin Part PINFO rganizatin Prir t deplyment n the target ECOA Platfrm(s), PINFO is rganised as fllws: PINFO are stred in directries specified in and Private PINFO is cmmn t all ASC Instances f a given ASC Implementatin (as it is stred at ASC Implementatin level) This rganisatinal structure is illustrated in Figure 18. Figure 18 PINFO rganizatin prir t deplyment Subsequent t deplyment n the target ECOA Platfrm(s), PINFO is rganised as fllws: PINFO are stred in the ECOA Infrastructure, which is specific t each ECOA Platfrm. The ECOA Infrastructure shall ensure nn-cnflicting access t PINFO by Mdule Instances. DGT F/IAWG-ECOA-TR-007 Issue 6 24

31 PINFO API The ECOA Infrastructure is respnsible fr making PINFO accessible t Mdule Instances: PINFO used by a Mdule Instance shuld be made accessible t that Mdule Instance prir t the INITIALIZE peratin being invked when it is in the IDLE state, PINFO used by a Mdule Instance shuld cease t be accessible t that Mdule Instance when it ges t the IDLE state and any nging SHUTDOWN peratin has returned. Frm a Mdule Instance pint f view, PINFO has the fllwing frm, illustrated by Figure 19: PINFO is an array f bytes, Nte: the use f PINFO may limit ASC prtability if the binary PINFO data and the functinal cde that accesses it are nt designed t explicitly handle endianness in a platfrm independent way (i.e. byte rder when accessing PINFO). It is up t ASC suppliers t ensure that binary PINFO data is managed in a platfrm independent way. PINFO has an index, dented by PINFO index which indicates the current psitin in the array f bytes at which the next access will ccur: PINFO index is expressed as a number f bytes, PINFO index starts frm zer. PINFO has a size dented by PINFO'size. DGT F/IAWG-ECOA-TR-007 Issue 6 25

32 ASC Instance Mdule Instance PINFO CONTAINER API Read, Seek PINFO index ECOA Infrastructure PINFO size Reads bytes frm PINFO Updates PINFO index psitin (Re)initializes PINFO index psitin Figure 19 PINFO API Mdule Instances invke the fllwing Cntainer API fr accessing PINFO: PINFO Read: The Mdule Instance asks its Cntainer t read a number f cnsecutive bytes in the PINFO, starting at PINFO index psitin. The Cntainer prvides the bytes read t the Mdule Instance. The Cntainer ensures that PINFO'size is nt exceeded. The Cntainer increments PINFO index accrding t the number f read bytes. PINFO Seek: The Mdule Instance asks its Cntainer t mve PINFO index frward r backward by a specified number f bytes relative t a starting psitin. The starting psitin is ne f start f PINFO, current index, size f PINFO. The Cntainer mves PINFO index and returns its new psitin t the Mdule Instance. The Cntainer ensures that the new PINFO index psitin is greater than r equal t zer. The Cntainer ensures that PINFO'size is nt exceeded. DGT F/IAWG-ECOA-TR-007 Issue 6 26

33 The ECOA Infrastructure sets the PINFO index fr a Mdule Instance t zer just prir t it invking an INITIALIZE Mdule peratin Driver Cmpnents Driver Cmpnents prvide a means f allwing interactins between the ECOA and nn-ecoa dmains. This interactin may be with hardware devices r with nn-ecoa sftware. As a result, driver cmpnents may be less prtable than ther ECOA cmpnents. Any Driver Cmpnent must cmply with any specified prvided and required Quality f Service. Figure 20 Driver Cmpnent Example Interactin with Bespke APIs Figure 20 shws an example Driver Cmpnent whse mdule interacts with nn-ecoa sftware thrugh tw bespke APIs. At pint 1 a Mdule Operatin is invked n the Client Mdule Instance frm a Service Operatin. During this executin, the Mdule Instance invkes sme nn-ecoa functinality via a bespke API at pint 2. The nn-ecoa functinality is implemented by sme bespke sftware at pint 3 (e.g. an SQL database), and perfrms sme functinality prir t returning cntrl. DGT F/IAWG-ECOA-TR-007 Issue 6 27

34 The Mdule Instance cntinues peratin and invkes sme alternate nn-ecoa functinality via a secnd bespke API at pint 4. This alternate functinality is implemented at pint 5 by sme nn-ecoa sftware prvided by the cmpnent supplier. This nn-ecoa sftware may interact with ther sftware r hardware as required by the cmpnent prvider. Once cmplete, cntrl is returned back t the Mdule Instance. Any nn-ecoa sftware invked by an ECOA Driver Cmpnent must ensure that it als cmplies with the ECOA Inversin f Cntrl principle, as it is effectively part f the Mdule Instance thread f cntrl. If any bespke sftware requires an interactin that wuld blck the Mdule Instance frm cntinung, then this must be implemented by a separate thread f cntrl. Within a Driver Cmpnent, an ECOA Mdule Instance can make use f a bespke API t invke nn- ECOA sftware as described abve. An external interface is defined [Architecture Specificatin Part 4] t allw nn-ecoa sftware t asynchrnusly interact with ne r mre ECOA Mdule Instances r ECOA dynamic Trigger Instances. The externally generated event may be cnnected t ne r mre Mdule Instance peratins and/r Dynamic Trigger instance event peratins fllwing the nrmal rules f Event Links. This allws an externally generated event t be delivered t multiple Mdule Instances and/r Dynamic Trigger Instances within the Cmpnent Instance. An external interface may nt be cnnected t a Prvided r Required Service Operatin. Figure 21 Driver Cmpnent Example External Asynchrnus Interactin Figure 21 shws an example f hw nn-ecoa sftware asynchrnusly interacts with ne Mdule Operatin f a single Mdule Instance thrugh a defined external interface (pint 1). When the ECOA external interface (implemented by the cntainer) is invked by the nn-ecoa sftware at pint 1, an event is placed int the Mdule Instance queue at pint 2. The event will be prcessed as usual, and the assciated peratin will be invked n the Mdule Instance at pint 3. The Mdule Instance can then perfrm the apprpriate prcessing fr the received event. DGT F/IAWG-ECOA-TR-007 Issue 6 28

35 Due t the chsen apprach, nly ne single instance f ne given driver cmpnent implementatin can be deplyed per prtectin dmain; this limitatin des nt preclude the deplyment f several driver cmpnent instances within the same prtectin dmain if they refer t distinct driver cmpnent implementatins. Any Mdule Instances f the same ASC Instance that are linked t the same external peratin must be deplyed in the same Prtectin Dmain alng with the nn-ecoa sftware that invkes the assciated External API. 8 Services 8.1 Overview Services prvided by a Cmpnent instance are cnsidered technically available at any time. Hwever, as specified in sectin 9.1, the ECOA Infrastructure discards any peratin arriving t a Mdule Instance when that Mdule Instance is nt in the RUNNING state. The functinal availability f a prvided Service is left under the respnsibility f the Prvider cmpnent: it is likely t be dependent upn a cmbinatin f cmpnent internal lgic and the functinal availability f any required Services necessary in rder t successfully prvide its Service. Nte: the functinal availability f a prvided Service may be cnveyed t client ASCs by expressing it as a Service Operatin (e.g. a Versined Data). The pssible cnnectins between the prvided and required Services f Applicatin Sftware Cmpnents in an ECOA system are determined by the Assembly Schema. This prvides details f the Service Links (called Wires in the Assembly Schema) between Services. Service discvery is static, and a Client has nly a single Prvider f a Service. The links between prviders and requirers f such Services are statically pre-determined by the Assembly Schema and are established at system start up. The links between Services are described by the Wires in the Final Assembly Schema. Each Wire has a single Requirer f a Service (identified as a surce in the schema) and a single Prvider f the Service (identified as a target in the schema). There may be multiple Requirers f the same Service; the cnnectins between them are determined by the Wires in the Assembly Schema 8.2 Service Link Behaviur Intrductin A Service Link cnnects Applicatin Sftware Cmpnents tgether 1. Each Service Link cnnects ne Prvided Service t ne Required Service which refers t the same Service Definitin (which cnsists f peratins i.e. Events, Request Respnse and Versined Data). This is shwn in Figure The wiring f Applicatin Sftware Cmpnents thrugh Service Links may lead t cyclic dependencies between them: the crrectness and the cnsistency f the resulted Assembly Schema is the respnsibility f the System Designer. DGT F/IAWG-ECOA-TR-007 Issue 6 29

36 required service ServiceLink 1 * 1 1 prvided service Figure 22 Service Links It is necessary t specify the behaviur f each peratin acrss the Service Links. This is because it is different fr each type f peratin Summary f Behaviur When a Service Definitin includes an Event Sent By Prvider peratin, the Event (and its assciated typed data) sent by any Prvider is received by all Requirers linked t the Prvider (the Event data is distributed frm the Prvider t many Requirers). Similarly, when a Service Definitin includes an Event Received By Prvider peratin, the assciated typed data sent by any Requirer is received by the Prvider. When a Service Definitin includes a Versined Data peratin, the prviding Applicatin Sftware Cmpnent that is linked t the Prvided Service may supply that data. Applicatin Sftware Cmpnents that are linked t the Required Service read the mst recent value f the data prvided by the Prvider. Fr a Request-Respnse peratin referenced in a Service Link, the Request frm the Client is addressed (directed) t the Prvider (Server). These behaviurs are summarized in Table 1. DGT F/IAWG-ECOA-TR-007 Issue 6 30

37 Table 1 Behaviur acrss a Service Link Operatin Prvider Requirer Event Operatins sent_by_prvider The Event and its assciated typed data is sent t all Requirers Receives the Event and its assciated typed data frm the Prvider defined in the Assembly Schema. received_by_prvider Receives the Event and its assciated typed data frm all Requirers. The Event and its assciated typed data is sent t the Prvider Request-Respnse Operatins Receives Requests frm all Requirers (Clients) Prvider as defined in the Assembly Schema. Versined Data Operatins Updates data fr all Requirers (Readers) Prvider (Writer) as defined in the Assembly Schema. The behaviur abve is true when the server is technically accessible. Examples f situatins where the server is nt technically accessible are: lss f cnnectin between Platfrms, remte Platfrm dwn, server Mdule Instance nt in RUNNING state. When the server is nt technically accessible the fllwing behaviur is applied: Event The event is discarded by the ECOA Infrastructure Request-Respnse NO_RESPONSE returned by the ECOA Infrastructure t the client as sn as pssible r after the Request Respnse timeut set by the ASC supplier has expired. Versined data The versined data is always accessible by the writer but any publicatin may nt actually be distributed t the clients. The latest value f the versined data is always accessible by the reader, but the versined data may becme stale Examples Nte: this sectin illustrates queues at ASC level fr cnceptual purpse nly. Actual queues are implemented at Mdule level within ASCs. DGT F/IAWG-ECOA-TR-007 Issue 6 31

38 Requiring Cmpnent R1 Requiring Cmpnent R2 Prviding Cmpnent P1 Figure 23 Example Assembly Schema In the abve Assembly Schema, tw Applicatin Sftware Cmpnents R1 and R2 are cnnected, via Service Links, t ne Applicatin Sftware Cmpnent P1. P1 is the Service Prvider fr R1 and R2. "Sent by Prvider" Events One queue is created fr each requiring cmpnent S: Service Definitin e: event (sent by prvider) received sent Requiring Cmpnent R1 Requiring Cmpnent R2 q1 q2 Prviding Cmpnent P1 Figure 24 Generatin f an Event An Event e Sent by Prvider in Service S translates t: An Event queue (q1,q2) is created fr each Requiring Cmpnent (R1, R2); An Event sent by the Service Prvider (P1) is received by all its Requirers (R1 and R2). DGT F/IAWG-ECOA-TR-007 Issue 6 32

39 "Received by Prvider" Events One queue is created fr each requiring cmpnent S: Service Definitin e: event (received by prvider) received sent Requiring Cmpnent R1 Requiring Cmpnent R2 q1 Prviding Cmpnent P1 Figure 25 Cnsumptin f an Event An Event received by Prvider in a Service translates t: An Event queue (q1,q2) is created fr the prviding Cmpnent (P1); An Event sent by a Requirer (R1, R2) is received by the Service Prvider (P1) All Requirers are allwed t send the Event. Request-Respnse S Service Definitin rr : requestrepnse Synchrnus Case request respnse Requiring Cmpnent R1 Requiring Cmpnent R2 qp1 Prviding Cmpnent P1 Figure 26 Synchrnus Request-Respnse Operatin DGT F/IAWG-ECOA-TR-007 Issue 6 33

40 S Service Definitin rr : requestrepnse Asynchrnus Case request respnse Requiring Cmpnent R1 Requiring Cmpnent R2 qr1 qr2 qp1 Prviding Cmpnent P1 Figure 27 Asynchrnus Request-Respnse Operatin In Figure 26 and Figure 27, Service definitin S defines a single Request-Respnse peratin (rr). This translates t: Service Requirers (R1 and R2) issue a Request t their Prvider (P1). The Service Prvider (P1) respnds t the received Requests. Fr Synchrnus Request-Respnse peratins, the Requiring Cmpnent is blcked until the Respnse is received. Fr Asynchrnus Request-Respnse peratins, the Requiring Cmpnent is nt blcked. The Respnse is received at sme later time and prcessed by a callback functin. Requests int the Prvider are queued (qp1) until the relevant Request_Received API callback functin is called by the Prvider Cmpnent's Cntainer. This will cause additinal blcking delays t Requirers f Synchrnus Request-Respnse peratins. Respnses t Asynchrnus Request-Respnse peratins are queued in the Requiring Cmpnent s queue (qr1, qr2) until the relevant Respnse_Received API callback functin is called by the Requirer Cmpnent's Cntainer. Respnses t Synchrnus Request-Respnse peratins are nt queued in the Requiring Cmpnent which will be blcked waiting in the Request_Sync API functin fr the Respnse. Versined Data Figure 28 Versined Data DGT F/IAWG-ECOA-TR-007 Issue 6 34

41 In Figure 28 Service definitin S defines ne Versined Data peratin (d). This translates t: One instance f data 2 (d1) created The Versined Data instance is written by nly ne Applicatin Sftware Cmpnent and can be read by many Applicatin Sftware Cmpnents. Nte: as specified in 7.5, Versined Data acrss service links can nly be dne with access cntrl. 9 ECOA System Management 9.1 Lifecycle A Cmpnent Instance is cmpsed f Mdule Instances. The Runtime Lifecycle f a Mdule Instance defines its runtime state. Figure 29 illustrates the Mdule Runtime Lifecycle. 2 This is a lgical view frm the pint-f-view f the Cmpnent. In an actual platfrm implementatin, the data may be physically distributed and synchrnized acrss the prcessing ndes in different ways. DGT F/IAWG-ECOA-TR-007 Issue 6 35

42 Figure 29 Mdule Runtime Lifecycle A Mdule Instance has three pssible lgical states: IDLE state reached after instantiatin, fatal errr raising r shutdwn. READY state reached when the mdule has been initialized. RUNNING state where the Mdule Instance is handling incming Mdule Operatins. In the RUNNING state, the Mdule Instance may be blcked when invking Cntainer Interface blcking peratins such as synchrnus request-respnses. A Mdule Instance can transitin between these states as shwn in Figure 29. The states and transitins are managed by the Cntainer, which invkes Mdule Interface entry pints fr each state change. The Mdule Instance states d nt necessarily reflect the states f the underlying OS tasks which supprt the Mdule Instances, e.g. a Mdule Instance may be in a RUNNING state while the underlying task may be in a ready state waiting fr the CPU resurce. The Mdule Interface cntains entry pints that are invked by the Cntainer as a result f a Mdule Lifecycle state change (such as upn ECOA System start up / shutdwn, r upn a recvery actin triggered by the ECOA Fault Handler). They are: INITIALIZE START STOP DGT F/IAWG-ECOA-TR-007 Issue 6 36

43 SHUTDOWN The lifecycle f Mdule Instances within a Cmpnent instance are managed by the ECOA Infrastructure Mdule Startup Upn start-up f the ECOA System, the ECOA Infrastructure is respnsible fr the allcatin and initializatin f all the resurces (threads, libraries, bjects, etc.) needed t execute the functinality f the Mdule Instances and their Cntainers fr each Cmpnent Instance. Cmpnent Instances may be started in any rder r even in parallel; hwever the fllwing describes the startup rder f the Mdule Instances within each Cmpnent Instance: Fllwing allcatin and initialisatin f resurces each Mdule Instance is brught t the IDLE state. Then, with the help f Lifecycle Events, the ECOA Infrastructure requests all Mdules Instances f the Cmpnent Instance t INITIALIZE in the fllwing sequential rder: All Dynamic Triggers, Then all peridic Triggers, Finally all ther Mdule Instances. Each Mdule Instance perfrms any actins required t initialize such as allcating further resurces, setting its internal variables and/r reading its Prperties t reach a technically cherent and initialized internal state. When all Mdule Instances f the Cmpnent Instance are in READY state, the ECOA Infrastructure requests all Mdule Instances f the Cmpnent Instance t START in the fllwing sequential rder: All Dynamic Triggers, Then all peridic Triggers, Finally all ther Mdule Instances. At this pint, each Mdule Instance has the pprtunity (via its START peratin) t perfrm any actins relevant t its transitin t the RUNNING state (these are likely t be specific t the functinality f the design). Once started the Mdule Instance enters the RUNNING state. Nte: Peridic Triggers and dynamic Triggers shuld be started first because the verhead f starting triggers is mre cntrllable than nrmal mdules. At this stage, all types f Mdule Instance within the Cmpnent Instance are in RUNNING state. Nte: further functinal initializatin f the ECOA System may take place nce Mdule Instances have reached the RUNNING state (hwever frm the mdule lifecycle pint f view, the technical initializatin f Mdule Instances is cnsidered t be cmplete at this stage). The fllwing are the steps taken t change the state f a Mdule Instance: the ECOA Infrastructure requests a Mdule Instance lifecycle state change the Cntainer invkes the apprpriate entry pint in the Mdule Interface when the entry pint returns the Cntainer changes the state f the Mdule Instance DGT F/IAWG-ECOA-TR-007 Issue 6 37

44 9.1.2 Mdule Run-time Behaviur Lifecycle Events that d nt represent a valid transitin frm the current state, as shwn by the Mdule Lifecycle state diagram in Figure 29, are discarded, and the fault management Infrastructure will be ntified (see sectin 9.3). Lifecycle Events are activating peratins. Lifecycle Events have n pririty ver ther peratins: Operatins arriving befre the START entry-pint has returned are discarded, as illustrated in Figure 30. The ECOA Infrastructure discards any peratin (except legal lifecycle events) arriving t a Mdule Instance when that Mdule Instance is nt in the RUNNING state (i.e the peratin is nt queued), as illustrated n Figure 30 and Figure 31. Figure 30 Mdule Run-time Behaviur Startup On receipt f STOP Events, peratins already executing are allwed t cmplete and peratin calls may cntinue t be queued but are finally discarded as sn as the STOP r SHUTDOWN entry pint has been executed (i.e. nce the Mdule is nt in RUNNING state anymre, the Mdule queue is cleared). Figure 31 Mdule Run-time Behaviur Stp Operatins arriving after receipt f SHUTDOWN Events (whilst in RUNNING) may be queued, but are finally discarded as sn as the SHUTDOWN entry pint has been executed (i.e. nce the Mdule is nt in RUNNING state anymre, the Mdule queue is cleared), as illustrated in Figure 32. DGT F/IAWG-ECOA-TR-007 Issue 6 38

45 Operatins arriving whilst in READY cntinue t be discarded and the SHUTDOWN Event des nt change this, as illustrated in Figure 32. Figure 32 Mdule Run-time Behaviur Shutdwn A Mdule shuld nt invke any Request-Respnse peratins in its Cntainer Interface as part f the implementatin f a Mdule Lifecycle peratin. The Mdule may hwever invke Event r Versined Data peratins in this case Mdule Shutdwn When its SHUTDOWN entry pint is called the Mdule Instance may de-allcate any assciated resurces (thse previusly allcated during INITIALIZE). When its SHUTDOWN entry pint returns the Infrastructure de-allcates the resurces used by the Mdule Instance, after which the Mdule Instance enters the IDLE state. Whenever a Mdule Instance enters the IDLE state, its queue is cleared and the Infrastructure releases all Versined Data handles assciated with it Graceful vs fast shutdwn Graceful shutdwn prcedure The ECOA Infrastructure may call the STOP and SHUTDOWN entry pints f Mdule Instances fr the purpse f perfrming a graceful shutdwn prcedure. A graceful shutdwn may be useful fr simulatin purpses in rder t be able t stp, shutdwn and restart selected ASCs and let them perfrm user-specified cde as part f these entry pints. It may als be DGT F/IAWG-ECOA-TR-007 Issue 6 39

46 useful fr driver cmpnents s that these can free any specific underlying resurce befre becming IDLE. ECOA itself des nt mandate ECOA Platfrms t be capable f graceful shutdwn. In rder fr a graceful shutdwn prcedure t be pssible, the capability fr it needs t be prcured within the ECOA Platfrm. In additin, the functinal specificatins f targeted ASCs need t tell the ASC supplier what applicatin cde t implement in the STOP and SHUTDOWN entry pints Fast shutdwn prcedure As part f sme recvery actins (see sectin ), the ECOA Infrastructure may perfrm a fast shutdwn prcedure f Mdule Instances, by putting them int IDLE state withut invking their STOP r SHUTDOWN entry pints. 9.2 Health Mnitring Unlike Fault Handling, ECOA assumes that Health Mnitring is related t applicatin and functinal system design and that it can be addressed by designing ASCs fr this purpse. 9.3 Fault Handling Errr Categrizatin Errr is a glbal term that encmpasses: Applicatin errrs: cnsequences f faults ccurring at applicatin Mdule level. Their management is the respnsibility f the cmpnent prvider. An Errr can be: A fatal Errr: the Mdule knws it cannt recver n its wn and uses mechanisms prvided by the Infrastructure t reprt the Errr A nn-fatal Errr: the Mdule may be able t recver n its wn (in case f minr Errrs) r it may reprt the Errr Infrastructure errrs: cnsequences f faults ccurring at ECOA Infrastructure level, i.e. Mdule Cntainer level, Prtectin Dmain level, Cmputing Nde level r Cmputing Platfrm level. Their management is the respnsibility f the system architect and system integratr Errr Prpagatin and Recvery Actins Errrs can be detected at several levels: Mdule level (applicatin errrs) Mdule Cntainer level (Infrastructure errrs) Prtectin Dmain level (Infrastructure errrs) Cmputing Nde level (Infrastructure errrs) Cmputing Platfrm level (Infrastructure errrs) Depending n the nature f the errr (applicatin errr r Infrastructure errr) and the level f detectin, fault management may prvide recvery prcedures at: Mdule level Cmpnent level Prtectin Dmain level Cmputing Nde level DGT F/IAWG-ECOA-TR-007 Issue 6 40

47 Cmputing Platfrm level The recvery prcedures fr Infrastructure errrs, prvided by the ECOA Infrastructure, are dne by an entity named Fault Handler. ECOA Fault Handling at infrastructure level may be implemented int ne r several such entities n a single platfrm. The scpe f the ECOA Fault Handler(s) cannt be wider than platfrm level (e.g. in a system made f tw platfrms cnnected thrugh ELI, there shall be at least ne ECOA Fault Handler entity per platfrm). The ECOA Infrastructure assciates a timestamp t any errr that it raises t ECOA Fault Handler(s) Applicatin Errrs Prpagatin and Recvery Actins Applicatin errrs may be detected by an applicatin Mdule. The Cmpnent prvider determines the recvery actins (if any) t be applied by an applicatin Mdule when an applicatin errr ccurs. If an applicatin errr is detected by an applicatin Mdule, the recvery prcedure may be: In case f nn fatal applicatin errr, the Mdule may Handle the applicatin errr if it has been cded t recver frm that type f errr, Raise the applicatin errr t the Fault Handler thrugh raise_errr. The Fault Handler will determine the Recvery Actin. In case f fatal applicatin errr, the applicatin Mdule uses the raise_fatal_errr API. The errr is autmatically sent t the Fault Handler All applicatin Mdules within the faulty cmpnent are immediately placed int the IDLE state by the ECOA Infrastructure. The Fault Handler will determine the Recvery Actin t be applied, if any. Figure 33 illustrates the prpagatin f Nn-fatal applicatin errrs. Nn fatal Errr detected yes is the fault handled by the Mdule? n Mdule recvery actin is perfrmed Errr raised t the Fault Handler Fault Handler recvery actin is perfrmed Figure 33 Prpagatin path f nn-fatal applicatin errr Figure 34 illustrates the prpagatin f fatal applicatin errrs. DGT F/IAWG-ECOA-TR-007 Issue 6 41

48 Fatal Errr detected Cmpnent is shutdwn Errr raised t the Fault Handler Fault Handler recvery actin is perfrmed Figure 34 Prpagatin path f fatal applicatin errrs Infrastructure Errrs prpagatin and Recvery Actins An Infrastructure errr is a fault detected at Infrastructure level, i.e. at Mdule Cntainer level, Prtectin Dmain level, Cmputing Nde level r Cmputing Platfrm level. Figure 35 illustrates Infrastructure errr prpagatin: If the Infrastructure errr invlves the Fault Handler (itself r its Prtectin Dmain r its Cmputing Nde): If there is nly ne Fault Handler instance n the ECOA platfrm, it is handled by the ECOA platfrm that applies a default recvery actin Otherwise it may be handled by anther Fault Handler (r, still, by the ECOA platfrm), depending n the implementatin chsen by the platfrm supplier Otherwise: If the Infrastructure errr is detected by a Mdule Cntainer, it is raised t the Fault Handler If the Infrastructure errr cmes frm a Prtectin Dmain, a Cmputing Nde, r anther Cmputing Platfrm, it is directly detected by the Fault Handler Then, the Fault Handler lgs the fault and applies the crrespnding recvery prcedure. DGT F/IAWG-ECOA-TR-007 Issue 6 42

49 Figure 35 Prpagatin path f infrastructure errrs The parameterizatin f the Fault Handler recvery rutines (i.e. the recvery actins t be applied) is the respnsibility f the system architect and the system integratr. Recvery actins fr Infrastructure errrs may be applied at sme levels, depending n the capabilities prcured in the ECOA Platfrm: At Cmpnent level, the Fault Handler may: Shutdwn the faulty Cmpnent Warm/cld restart the faulty Cmpnent At Prtectin Dmain level, the Fault Handler may: Shutdwn the Prtectin Dmain Warm/cld restart the Prtectin Dmain At Cmputing Nde level, the Fault Handler may: Shutdwn the Cmputing Nde Warm/cld restart the Cmputing Nde At Cmputing Platfrm level, the Fault Handler may: Shutdwn the Cmputing Platfrm Warm/cld restart the Cmputing Platfrm Change the deplyment Nte: the warm restart recvery actins supprted by the ECOA Platfrm shuld be cnsistent with that ECOA Platfrm ability t maintain the warm start cntext f Mdule Instances upn thse recvery actins. The cmpnent shutdwn actin cnsists f the Infrastructure putting all Mdule Instances f the targeted Cmpnent Instance in idle state (with the Trigger Instances being the first). The Infrastructure frees DGT F/IAWG-ECOA-TR-007 Issue 6 43

50 assciated resurces, withut calling the shutdwn entry pint f these ptentially faulty Mdule Instances. Therefre, this is a fast shutdwn and nt a graceful functinal shutdwn and is nt part f the Mdule Lifecycle. The cmpnent restart actin cnsists f the Infrastructure triggering a cmpnent shutdwn actin, fllwed by initialize and start lifecycle actins accrding t rders defined in In rder t enable fault filtering, the Fault Handler has a cntext which can be used as memry t stre the number f ccurrences f a fault ver a time frame. As an example, this culd be used t enable a spradic fault t be distinguished frm a recurrent fault and applying a recvery actin nly if a given fault ccurs mre than X times in a given time frame. Figure 36 summarizes the errr prpagatin path and applicable recvery actins. Fault handling at applicatin level Levels Actins Restart cld/warm Fault handling at infrastructure level Cmpnent Prtectin Dmain Cmputing Nde Cmputing Platfm OK OK OK OK Shutdwn OK OK OK OK if RAISE_ERROR r RAISE_FATAL_ERROR Applicatin Mdule Lad new cmpsite Fault Handler lg OK applicable recvery actins errr errr Figure 36 Errr prpagatin path Operatins and faults ECOA prvides the cmpnent supplier with three types f peratins fr use in applicatin mdules: Event Versined Data Synchrnus and Asynchrnus Request/Respnse Each f these peratins has specific behaviurs regarding identified errrs and infrastructure errrs. The fllwing sectin prvides Infrastructure errrs handled by the Fault Handler. Errr cdes returned t the Mdule are prvided in Architecture Specificatin Part 4. DGT F/IAWG-ECOA-TR-007 Issue 6 44

51 Nte: Figures in this sectin prvide examples f infrastructure errr prpagatin paths t the Fault Handler. Actual paths may depend n Platfrm implementatin. Event: Infrastructure errrs handled by the Fault Handler: RESOURCE_NOT_AVAILABLE client cntainer unable t send the event OPERATION_NOT_AVAILABLE server cannt handle the event UNKNOWN_OPERATION requested peratin ID is invalid Figure 37 illustrates these behaviurs. Client Client Mdule event Client Cntainer Fault utside client area: n server side n cmmunicatin link Client Client Mdule event Client Cntainer Errr detected by the client cntainer RESOURCE_NOT_AVAILABLE r OPERATION_NOT_AVAILABLE r UNKNOWN_OPERATION Fault Handler Figure 37 Event faults prpagatin behaviur Request-Respnse: Request faults: Infrastructure errrs handled by the Fault Handler: RESOURCE_NOT_AVAILABLE client cntainer unable t send the request OPERATION_NOT_AVAILABLE server cannt handle the request UNKNOWN_OPERATION requested peratin ID is invalid Respnse faults: Infrastructure errrs handled by the Fault Handler: DGT F/IAWG-ECOA-TR-007 Issue 6 45

52 RESOURCE_NOT_AVAILABLE server cntainer unable t send the respnse OPERATION_NOT_AVAILABLE client cannt handle the respnse OVERFLOW server cntainer unable t retain the request (maxcncurrentrequests has been reached) The Figure 38 and Figure 39 illustrate these behaviurs. Figure 38 Request-Respnse faults prpagatin behaviur part 1 DGT F/IAWG-ECOA-TR-007 Issue 6 46

53 Figure 39 Request-Respnse faults prpagatin behaviur part 2 Nte that in the case f a NO_RESPONSE errr being detected by the client Cntainer it is pssible that tw recvery actins are perfrmed as a result f a single riginating fault. This is due t the fact that the Infrastructure errr is handled by the Fault Handler, but in additin, it is als pssible that the Mdule raises an errr t the Fault Handler. Nte als that when a fault is detected utside f the client area after a request call, the platfrm supplier has the pssibility t chse between tw implementatins: he can chse t send NO_RESPONSE t the client thugh the ECOA Infrastructure, r d nthing and wait fr the timeut (if specified) t happen n the client side (which causes the client Cntainer t send a NO_RESPONSE t the client Mdule). Versined Data: Get_read_access: Infrastructure errr handled by the Fault Handler: RESOURCE_NOT_AVAILABLE client cntainer unable t access the memry slt Release_read_access DGT F/IAWG-ECOA-TR-007 Issue 6 47

54 Infrastructure errr handled by the Fault Handler: RESOURCE_NOT_AVAILABLE client cntainer unable t access the memry slt Get_write_access: Infrastructure errr handled by the Fault Handler: RESOURCE_NOT_AVAILABLE client cntainer unable t access the memry slt Publish_write_access: Infrastructure errr handled by the Fault Handler RESOURCE_NOT_AVAILABLE client cntainer unable t access the memry slt Cancel_write_access: N Infrastructure errr The Figure 40 illustrates these behaviurs. DGT F/IAWG-ECOA-TR-007 Issue 6 48

55 Figure 40 Versined Data faults prpagatin behaviur 9.4 Mdule Cntext When a mdule is nt stateless, its surce cde shuld save states using the ptinal User Cntext r Warm Start Cntext within the Mdule Cntext, and shuld nt use glbal variables. This enables a platfrm t instantiate a single mdule implementatin multiple times and manage instance specific data cntained in the Mdule Cntext. User Cntext is instance specific ptinal data defined and managed by the mdule implementatin t allw it t maintain private state between each mdule peratin invcatin. This is analgus t the cntext f thread lcal strage in traditinal perating system implementatins. Warm Start Cntext is instance specific ptinal data defined and managed by the mdule implementatin t allw it t maintain private state between transitins f Mdule Lifecycle states where the transitin is an Initialize. The Mdule Implementatin has access t a Cntainer API s that it may request the Cntainer t save the Warm Start Cntext in nn-vlatile strage such that it may be restred during a future Warm Restart. Warm Restart can be initiated by the Fault Handler. The Infrastructure shall perfrm the save DGT F/IAWG-ECOA-TR-007 Issue 6 49

56 peratin atmically. If the save peratin fails n errr is returned t the calling Mdule; hwever an errr may be raised t the Fault Handler. The ability t maintain the warm start cntext f Mdule Instances upn warm start recvery actins is a Platfrm prcurement requirement. This is aimed at tailring ECOA Platfrms cmplexity t actual prcurement needs. As previusly stated, the warm restart recvery actins supprted by an ECOA Platfrm shuld be cnsistent with that ECOA Platfrm ability t maintain the warm start cntext f Mdule Instances upn thse recvery actins. In this sectin it is being assumed that this cnsistency is fulfilled. Example: if a Platfrm des nt supprt warm restart recvery actins at Cmputing Nde level and Cmputing Platfrm level, the Platfrm des nt need t save the warm start cntext in a way that wuld supprt these recvery actins. The calling mdule is respnsible fr determining the validity f the Warm Start Cntext. This may be achieved by incrprating additinal validity entries in the Warm Start Cntext itself. Fr a Cld Start frm pwer up r a Cld Restart initiated by a Fault Handler the saved value f the Mdule Warm Start Cntext is zered by the infrastructure. In this way fr a Warm Start initiated by a Fault Handler, the Mdule Warm Start Cntext is either restred frm a previusly zered versin, r the mst recently saved versin. Warm Start Cntext used by a Mdule Instance is zered/restred by the infrastructure prir t any activatin f the Initialize Mdule Instance entry pint. Nte: the ASC supplier shall initialize the User Cntext, if any, every time the Initialize Mdule Instance entry pint has been called, and shall never assume the User Cntext has been maintained by the Infrastructure. Fr restarts initiated by the physical platfrm, the Warm Start Mdule Cntext is nn-vlatile. Table 2 details the vlatility f the User and Warm Start Mdule Cntext. Table 2 User and Warm Start Mdule Cntext Vlatility User Cntext Warm Start Cntext Warm Cld Warm Cld Vlatile Vlatile Nn Vlatile Vlatile Figure 41 shws hw the Warm Start Cntext is managed thrugh these transitins. DGT F/IAWG-ECOA-TR-007 Issue 6 50

57 Figure 41 Management f Mdule Cntext Architecture Specificatin Part 4 describes the detail f hw the User Cntext and Warm Start Cntext are represented in varius languages, and the language bindings specifies the detail f the implementatin. User Cntext and Warm Start Cntext are ptinal. They are nly necessary fr Mdule Instances maintaining an internal state between peratin calls. Metamdel attributes n a Mdule Type (in an ASC Implementatin) are used t specify whether the User Cntext and/r Warm Start Cntext APIs shuld be made available fr any Mdule Instances f that Mdule Type. 10 Scheduling 10.1 Scheduling Plicy Supprt fr scheduling f deplyed Mdule/Trigger Instances is prvided by the underlying perating system. A deplyed Mdule/Trigger Instance is single-threaded and will be assigned a pririty by the System Integratr. The System Integratr shall take int accunt the relative pririties set by each Cmpnent Supplier n the Mdule/Trigger Instances declared in their Cmpnent Implementatin. Any ECOA platfrm shall respect the pririties defined by the System Integratr n deplyed Mdule/Trigger Instances. This implies: Deplying Mdule/Trigger Instances nt OS tasks accrding t their pririties: Mdule/Trigger Instances with different pririties shall nt be deplyed nt the same OS task, Mdule/Trigger Instances with identical pririties may be deplyed nt the same OS task, OS task pririties shall be set with respect t the pririty f the Mdule/Trigger Instances deplyed nt them. DGT F/IAWG-ECOA-TR-007 Issue 6 51

58 Mdule pre-emptin capability in ECOA platfrms: Any deplyed Mdule/Trigger Instance becmes eligible fr executin n the cmputing nde resurce whenever it receives an activating peratin in its queue (including receptin f the respnse f a synchrnus request-respnse), A Mdule/Trigger Instance currently executing n the cmputing nde resurce may be preempted by anther eligible Mdule/Trigger Instance f a higher pririty, A Mdule/Trigger Instance becmes ineligible fr executin n the cmputing nde resurce when its queue des nt cntain any activating peratin. The rules defined abve allw early verificatin f the system behaviur t take place at ECOA Mdule/Trigger Instance level, and prvide assumptins t facilitate Cmpnent integratin and reuse. Scheduling f OS tasks (which Mdule/Trigger Instances are being deplyed nt) is the respnsibility f the Infrastructure and any scheduling plicy supprted by the OS/Middleware may be used as required by the System Integratr, prvided that it respects the rules defined abve. Scheduling analysis is utside the scpe f ECOA; althugh it is anticipated that it wuld be carried ut fllwing existing, established methds. The type f scheduling analysis required will be dependent upn the chsen scheduling plicy Activating and nn-activating Mdule Operatins By default, Mdule Operatins are activating; the arrival f a new peratin implies the executin f the assciated entry-pint as sn as the Mdule Instance is able t execute. This schema is an Event-driven prgramming mdel. T disable this default behaviur, attributes are defined within the Cmpnent Implementatin at EventLink, RequestLink and DataLink level: activating which is a blean specifying the plicy used by the Cntainer t handle the peratin: when True (default value), the Cntainer activates the assciated entry-pint as sn as pssible. when False, the peratin is queued and remains pending. When an activating Mdule Operatin arrives t the same Mdule Instance thrugh anther Mdule Operatin Link, all pending Mdule Operatins that arrived befre the activating ne are then prcessed in FIFO rder and executed as any ther Mdule Operatin in accrdance with the pririty f the Mdule Instance. If nn activating Mdule Operatins are queued while this prcessing is dne, their prcessing is pstpned until the arrival f a new activating Mdule Operatin. It is envisaged that this type f mechanism culd be used t implement a time-driven prgramming mdel, which may allw fr easier schedule feasibility analysis. fifsize which is an integer specifying the maximum number f pending peratins f a single type at each receiving Cntainer level. The fifsize attribute is defined against an peratin Link; therefre different peratins can be specified t have different maximum queue sizes. When the maximum number is reached fr a given peratin, the receiving Cntainer discards the new incming Mdule Operatins assciated t the Link. Fr an incming Request Respnse, the receiver Cntainer sends back an errr message t the sending Cntainer in rder t ntify the Client f the failure. Hwever, this chice des nt apply t Mdule Lifecycle Operatins, which are necessarily activating peratins (i.e. it is nt pssible t define them as being nn-activating). NOTE Activating n DataLink is nly useful when assciated t a ntifying Versined Data (attribute ntifying set t true) (see 7.5.3). 11 Mdule Operatin Link Behaviur This sectin shws the relatinships between Service Operatins and Mdule Operatins. DGT F/IAWG-ECOA-TR-007 Issue 6 52

59 Figure 42 shws pssible interactins between Service Operatins and Mdule Operatins. DGT F/IAWG-ECOA-TR-007 Issue 6 53

60 Figure 42 Interactins between Service Operatins and Mdule Operatins This specificatin is develped by BAE Dynamics United Kingdm Limited and Lenard MW Ltd and the cpyright is wned by BAE basis and c-develpers f this specificatin make n warranties expressed r implied, including n warranties as t cmpleteness, DGT F/IAWG-ECOA-TR-007 Issue 6 54

61 The fllwing give mre details n each f these: The Grey bxes are the Services which are cllectins f Service Operatins and are described by Service Definitins. Required and Prvided Services are cnnected tgether using Service Links / Wires which are in Blue. The Yellw bxes are Service Operatins. The Purple bxes are Mdule Operatins which are entries nt Executable Entities which are in Green. The Orange bxes are Cntainer Operatins which are called frm an entry pint f a Mdule Instance. Incming Service Operatins are cnnected t Mdule Operatins using Mdule Operatin Links. Cntainer Operatins can be cnnected t utging Service Operatins using Mdule Operatin Links. Cntainer Operatins can be cnnected t Mdule Operatins using Mdule Operatin Links. Service Operatins cannt be mapped t ther Service Operatins using Mdule Operatin Links. All Mdule Operatin Links require Cntainer cde. The names f Service Operatins and Mdule Operatins which are cnnected tgether dn t have t match. A Request Respnse Service Operatin can nly be mapped t a single Mdule Operatin. Multiple Event Service Operatins can be mapped t the same Mdule Operatin. One Cntainer Operatin can be mapped t multiple Event Service Operatins. Versined Data is always Read r Written by an entry pint f a Mdule Instance using a Cntainer Operatin. 12 Utilities An ECOA Sftware Platfrm prvides utility functins fr acquiring time and fr generating lgs. The Architecture Specificatin Part 4 cntains mre detail regarding these functins. One f the ECOA Sftware Platfrm prvided functins is a methd fr allwing access t glbal time. It is a system specific decisin hw this glbal time is synchrnised, and at what precisin, hwever ECOA assumes that time values acquired thrugh these functins are synchrnised acrss the system. 13 Inter Platfrm Interactins In rder t prvide interperability between ECOA Sftware Platfrms, a message prtcl, termed ECOA Lgical Interface (ELI), has been defined. This message prtcl requires an underlying transprt prtcl fr its implementatin. The chice f the underlying transprt prtcl is left t the system designer depending n system-level requirements (perfrmance, security, etc.). As an example, a binding t the UDP transprt layer has been defined and can be fund in the Architecture Specificatin Part Cmpsites ECOA is fully cmpliant with the SCA Cmpsite cncept. A cmpsite is described by its definitin, the list f its Applicatin Sftware Cmpnents and the assciated Assembly Schema f these Applicatin Sftware Cmpnents. The Cmpsite will prvide several Services, each ne linked t ne r several Services r prvided by its Applicatin Sftware Cmpnents. This kind f Service Link is called a Prmtin Link. The Cmpsite will require several Services required by internal Applicatin Sftware Cmpnents. The link used here is als called a prmtin link. An Applicatin Sftware Cmpnent external t the Cmpsite is nly cnnected t DGT F/IAWG-ECOA-TR-007 Issue 6 55

62 Services prvided r required at Cmpsite level and has n knwledge f the internal Applicatin Sftware Cmpnents. ECOA allws the specificatin f Initial Assembly Schemas made f hierarchical cmpsites cntaining ECOA cmpnents in rder t help with design abstractins. Figure 43 shws an example Cmpsite cnstructed with fur Cmpnents. Figure 43 A Cmpsite 15 Use f Cmpsites in Platfrm Integratin The Final Assembly Schema used fr integratin n a given ECOA Platfrm is a flattened single Cmpsite that cntains as a minimum all ECOA Cmpnents that are deplyed nt that platfrm. Interactins with parts f the ECOA System that are deplyed nt ther platfrms are taken int accunt in the Final Assembly Schema by representing them as Cmpnents. This representatin is a lcal view t the particular platfrm and may nt crrespnd t the actual assembly n thse remte platfrms. Parts f an ECOA System that are deplyed nt multiple ECOA platfrms can be mdelled thrugh Cmpsites deplyed nt thse platfrms. Interactins between these Cmpsites that rely n interplatfrm messages using the ELI can be mdelled using the Crss Platfrm View [Architecture Specificatin Part 7]. This allws the capture f the functinal and lgical interfaces between platfrms in a way which is independent f the final assembly n each platfrm.. DGT F/IAWG-ECOA-TR-007 Issue 6 56