1、ASD STANDARD NORME ASD ASD NORM prEN 4660-005 Edition P 1 September 2009 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONAvenue de Tervuren, 270 - B-1150 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSIO
2、N Aerospace series Modular and Open Avionics Architectures Part 005: Final Draft of Proposed Standards for Software Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 005 : Dernire proposition des Standards pour Software Luft- und Raumfahrt Modulare und offene Avionikarchitektur
3、en Teil 005: Endgltiger Entwurf des Standards fr Software This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the needs of the European Aerospace Industry. It ha
4、s been technically approved by the experts of the concerned Domain following member comments. Subsequent to the publication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the s
5、tandard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement
6、 the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication 30 September 2009 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedure
7、s Domain Copyright 2009 by ASD-STAN Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 2 Contents Page Foreword. 10 0 Introduction. 11 0.1 Purpose 11 0.2 Document structure 12 1 Scope .
8、 12 1.1 Software Architecture Overview . 12 1.2 Software Architectural Components 13 2 Normative references . 15 3 Terms, definitions and abbreviations. 16 3.1 Terms and definitions 16 3.2 Abbreviations 16 4 System Functions. 19 4.1 System Management Function 19 4.2 Communication. 26 4.3 Security Ma
9、nagement. 45 4.4 Module Management 49 4.5 Mass Memory Management . 50 4.6 Graphics Management . 54 4.7 Power Management 56 4.8 Network Management. 58 4.9 Time Management. 61 5 Software Architecture Definition. 65 5.1 MSL 66 5.2 OSL. 71 5.3 RTBP 107 5.4 Application Layer 110 6 Direct Interfaces Defin
10、itions 117 6.1 APOS 117 6.2 MOS 189 6.3 SMBP 270 6.4 SMOS . 295 7 Logical Interfaces Definitions 340 7.1 OLI 340 7.2 GLI 347 7.3 SMLI . 372 7.4 MLI 380 8 Data Type Definitions . 438 8.1 IDL 438 8.2 Data Types. 439 9 Tailoring. 482 Copyright ASD-STAN Provided by IHS under license with AECMA Not for R
11、esaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 3 Annex A (normative) AGL.491 A.1 The Concept.491 A.2 Graphical Command Set.491 A.2.1 Overview.491 A.2.2 Command Listings 492 A.2.3 Auxiliary Library (AL) Definition 496 A.2.4 Video Library (VL) Definiti
12、on497 A.2.5 Texture Mapping Constraints.498 A.2.6 Display Frame and Synchronisation .500 A.2.7 Command Responses and Delays.500 Figures Page Figure 1 ASAAC Standard Documentation Hierarchy .11 Figure 2 ASAAC Three Layer Software Architecture .12 Figure 3 The Software Architecture Model13 Figure 4 Hi
13、erarchical Organisation of the System Management 20 Figure 5 GSM Decomposition for RE-Management (Example) .21 Figure 6 IA Application Control (Example)22 Figure 7 GSM Decomposition for Module Management (Example)23 Figure 8 Hierarchical Organisation of the AM (Example) 24 Figure 9 The ASAAC Communi
14、cation Stack.27 Figure 10 Types of Data Transfer.29 Figure 11 Communication Concept .30 Figure 12 Between AL Communication Routing 31 Figure 13 ASAAC Message in BMC Data Transfer .33 Figure 14 Multicast Scheme With a Single TC34 Figure 15 Multicast Scheme With Multiple Simple TCs 35 Figure 16 Data P
15、arallelism 36 Figure 17 Corner Turn .36 Figure 18 Corner Turn in Three Dimensions.37 Figure 19 Illustration of the Involved Services in DSP1 38 Figure 20 Data Representation.41 Figure 21 GSM Interfaces46 Figure 22 Main Security Related Architectural Components47 Copyright ASD-STAN Provided by IHS un
16、der license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 4 Figure 23 VC transferring Data Requiring Encryption IA1 controlling the IA managers IA2 and IA3; IA2, IA3, and IA4 each controlling 2 REs ACIA1IA2IA2IA3 IA4App1App2App3A
17、pp4App4 App4Figure 6 IA Application Control (Example) Application configuration control (Figure 6): An AC manager controlling IA1 and IA4; IA1 controlling IA2 and IA3; IA2 controlling the applications App1 and App2; IA3 controlling the applications App3 and App4 (redundant); IA4 controlling the redu
18、ndant application App4. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 23 ACIA1IA2 IA3 IA4 PCMMMM DPMNSMPCMMMM DPMSPMRACK 2 RACK 1 GPMDPMMODULEFigure 7 GSM Decomposition for Module
19、Management (Example) Application configuration control (Figure 7): An AC manager controlling IA1 and IA4; IA1 controlling IA2 and IA3; IA2 controlling the applications App1 and App2; IA3 controlling the applications App3 and App4 (redundant); IA4 controlling the redundant application App4. Configura
20、tion Data: The configuration data is obtained from the RTBP via SMBP. The reconfiguration is defined through dedicated sequences obtained via SMBP. Initialisation and Shut-Down: Initialisation and shut-down is performed on three different levels: Application, System, Module. 4.1.2 AM Function The AM
21、 function is responsible for the management and control of all AC dependent functions (functional applications) on the Application Layer (AL). It acts as an interface between the functional applications and a dedicated instantiation of the GSM. Hierarchical Organisation: The AM should only be locate
22、d on the AC- and IA-levels, as the RE level is resource-oriented, whereas the AC and IA levels are function-oriented. An example for the hierarchical organisation of the AM showing the assignment of functional applications to IAs is depicted in Figure 8: Copyright ASD-STAN Provided by IHS under lice
23、nse with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 24 GSM AM IA2 (Radar IA) IA3 (EW IA) IA1 (RF-IA) AC IA4 (Nav IA)Applications Air to Air Mode Air to Surface Mode Applications Threat WarningJammingApplications Flight Plan Map Dis
24、play GSMAMGSM AM GSMAM GSMAM Applications DASS Mgmt Applications Pilot Interaction Figure 8 Hierarchical Organisation of the AM (Example) Internal Interfaces: The standardised internal interface of the AM is the System Management Logical Interface (SMLI.) The SMLI includes a request-response protoco
25、l for the change of the logical configuration. External Interfaces: There are no standardised external interfaces of the AM. All external interfaces are application-dependent. 4.1.3 Error Handling ASAAC compliant systems require that software developers write their functional application code to int
26、erface with the underlying OS using the standardised service calls that comprise the APOS interface (section 6.1). However, it is possible at run-time for an APOS service not to perform correctly and to actually return an error status to the calling Application Process. This might be due to a real f
27、ault in the underlying system or by misuse of the APOS interfaces themselves (e.g. posting a semaphore before it has been created). In either case the fault is handled through a standardised process (see ASAAC2-GUI-32450-001-CPG Issue 01) in which the precise error identification is passed to the He
28、alth Monitoring function within the GSM. Any error handling shall be subject to the decisions made by the fault management function. In handling the error, the fault management function may delegate the error handling back to a functional Application Process by invoking the error handler thread of t
29、he Application Process. In this case, the complete error information shall be accessible to this error handler thread. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 25 The error in
30、formation shall be accessible to the application itself, but used for debugging purposes only. Exceptions to this rule are timeouts and resources, which are managed by the application. Note however that functional Application Processes shall handle situations where a called APOS service has timed ou
31、t. In this case, the application calling a service shall be informed by means of a return value. 4.1.4 Built-In Test The BIT Services provide the ability to execute module built-in tests and read their results. The built-in-test component provides access to all built-in-test routines available on th
32、e module. There are three different types of built-in test: Power-up built-in-test (PBIT), Continuous built-in-test (CBIT), Initiated built-in-test (IBIT). The OS provides the GSM with Services related to the BIT Management at the SMOS interface that are paired with services at the MOS interface: Ge
33、t PBIT Result: Retrieves the stored PBIT result, Start CBIT: Runs the CBIT processing and then returns. It allows a specific type of test to be run, or all tests to be run, Get CBIT Result: Retrieves the CBIT result, Start IBIT: Starts the IBIT processing, Get IBIT Result: Retrieves the stored IBIT
34、result. 4.1.4.1 Power-up Built-In Test (PBIT) PBIT is used to check the state of the module hardware as part of the boot process. The tests are run autonomously as part of the MSL before any control is applied from outside the module. The result of these tests is recorded in the MSL for retrieval by
35、 a GSM on a controlling module via the MLI. It is also available via a MOS/SMOS call to the local GSM. 4.1.4.2 Continuous Built-In Test (CBIT) CBIT is used to continuously check the health of the module during normal operation. CBIT is non-intrusive. The tests can be run either: Autonomously, if no
36、processor support is required to perform the test, Under the command of the GSM, if processor support is required to perform the test. Test results can also be obtained using two mechanisms: Callback, Polled, either as part of the calling mechanism or as a separate call. Copyright ASD-STAN Provided
37、by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 26 The various combinations of CBIT behaviour are described below: Table 2 CBIT Modes Run method Result Method Behaviour Autonomous Callback CBIT runs autonomousl
38、y and does not require control from outside the MSL. When a test fails, the indication of this is flagged to the OSL using a callback. The service getCbitResult is then used to retrieve the detailed information about the failure. Autonomous Polled CBIT runs autonomously and does not require control
39、from outside the MSL. When a test fails, the result is stored internally in the MSL. No indication is given to the OSL. GetCbitResult is then used periodically to retrieve any failure information. If no failure has occurred, no action is taken. If a failure has occurred, the detailed information abo
40、ut the failure is returned. Commanded Callback CBIT runs under the control of the OSL. When a test fails, the indication of this is flagged to the OSL using a callback. GetCbitResult is then used to retrieve the detailed information about the failure. Commanded Polled CBIT runs under the control of
41、the OSL. The time allowed to perform CBIT each time the service startCbit is called, is MSL specific. When a failure is detected, GetCbitResult is then used to retrieve the detailed information about the failure. 4.1.4.3 Initiated Built-In Test (IBIT) IBIT is used to check the state of the module ha
42、rdware as part of the fault management process. It performs a comprehensive test of the module in order to help during fault localisation. The tests can be run remotely under the control of a GSM on a controlling module via the MLI, or via a MOS/SMOS call (startIbit) from the local GSM when it is av
43、ailable. IBIT can be destructive in its operation. This means that the current configuration of the module cannot be guaranteed when the tests have been completed. Care must therefore be taken to ensure the system is not compromised when IBIT is used. Also, in the case of destructive testing, its us
44、e should be restricted to invocation via the MLI. The result of these tests is recorded in the MSL for retrieval by a GSM on a controlling module via the MLI or via a MOS/SMOS call (getIbitResult) from the local GSM if it started IBIT. 4.2 Communication 4.2.1 ASAAC Communication Model 4.2.1.1 Princi
45、ple The ASAAC Communication stack (see Figure 9) shall be supported by: VCs (provided by OSL), Transfer Connections (TC) (provided by MSL, hardware independent), Network Channels (NC) (provided by MSL, hardware dependent). Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo
46、reproduction or networking permitted without license from IHS-,-,-prEN 4660-005:2009 (E) 27 Virtual ChannelTransfer ConnectionNetwork ChannelVirtual ChannelTransfer ConnectionNetwork ChannelPeer to Peer CommunicationDirect InterfaceFigure 9 The ASAAC Communication Stack The ASAAC Communication shall
47、 support: One sender to one receiver (1:1), Multicast (one sender to n receivers (1:N), the case one sender to one receiver is a sub-set of the previous one (1:1), Distributed multi-cast (applicable to signal processing applications (M: N). 4.2.1.2 VC Inter-process communication is based on VCs. VCs
48、 show the following properties: Unidirectional, Message-oriented (i.e. one message definition is assigned to a VC), Managed by OSL (creation, deletion, routing), Predictable in terms of time and resource consumption. The concept allows a single transmitting process to send data to one or more receiving processes. A receiving process may be resident on the same Processing Element, the same CFM or even a different CFM to the sending process. The sending process has no knowledge of any receiving process; it merely outputs certain dat
