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 prEN 4660-005:2009 (E) 2 Contents Page Foreword. 10 0 Introduction. 11 0.1 Purpose 11 0.2 Document structure 12 1 Scope . 12 1.1 Software Architecture Overview . 12 1.2 Software Architectural Components 13 2 Normative references . 15 3 Terms, definitions and abbre
8、viations. 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 Management. 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 Manageme
9、nt. 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 Definitions 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
10、 MLI 380 8 Data Type Definitions . 438 8.1 IDL 438 8.2 Data Types. 439 9 Tailoring. 482 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
11、 (VL) Definition497 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 Model
12、13 Figure 4 Hierarchical 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
13、 ASAAC Communication 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 Fi
14、gure 16 Data Parallelism 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 prEN 4660-005:2009 (E)
15、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 IA4App1App2App3App4App4 App4Figure 6 IA Application Control (Example) Application configuration control (Figure 6): An AC manager controlling IA1
16、 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. prEN 4660-005:2009 (E) 23 ACIA1IA2 IA3 IA4 PCMMMM DPMNSMPCMMMM DPMSPMRACK 2 RACK 1 GPMDPMMODULEFigure 7 G
17、SM Decomposition for Module 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
18、 application App4. Configuration 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, Modu
19、le. 4.1.2 AM Function The AM 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:
20、The AM should only be located 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: prEN 4660-005:200
21、9 (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 Display GSMAMGSM AM GSMAM GSMAM Applications DASS Mgmt Applications Pilot Interaction Figure 8 Hierarchical Organisati
22、on 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 protocol for the change of the logical configuration. External Interfaces: There are no standardised external interfaces o
23、f 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 interface with the underlying OS using the standardised service calls that comprise the APOS interface (section 6.1).
24、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 fault in the underlying system or by misuse of the APOS interfaces themselves (e.g. posting a semaphore before it ha
25、s 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 Health Monitoring function within the GSM. Any error handling shall be subject to the decisions made by the fault man
26、agement 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 the Application Process. In this case, the complete error information shall be accessible to this error handler thre
27、ad. prEN 4660-005:2009 (E) 25 The error information 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 situation
28、s where a called APOS service has timed out. 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
29、all built-in-test routines available on the 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 pai
30、red with services at the MOS interface: Get 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, G
31、et IBIT Result: Retrieves the stored IBIT 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 tes
32、ts is recorded in the MSL for retrieval by 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 tes
33、ts can be run either: Autonomously, if no 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 s
34、eparate call. 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 autonomously and does not require control from outside the MSL. When a test fails, the indication of this is fla
35、gged 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 from outside the MSL. When a test fails, the result is stored internally in the MSL. No indication is
36、 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 about the failure is returned. Commanded Callback CBIT runs under the control of the OSL. When a test fa
37、ils, 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 the OSL. The time allowed to perform CBIT each time the service startCbit is called, is MSL specific.
38、 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 hardware as part of the fault management process. It performs a comprehensive test of the module in ord
39、er 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 available. IBIT can be destructive in its operation. This means that the current configuration of the m
40、odule 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 use should be restricted to invocation via the MLI. The result of these tests is recorded in the MSL fo
41、r 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 Principle The ASAAC Communication stack (see Figure 9) shall be supported by: VCs (provided by OSL), Transf
42、er Connections (TC) (provided by MSL, hardware independent), Network Channels (NC) (provided by MSL, hardware dependent). prEN 4660-005:2009 (E) 27 Virtual ChannelTransfer ConnectionNetwork ChannelVirtual ChannelTransfer ConnectionNetwork ChannelPeer to Peer CommunicationDirect InterfaceFigure 9 The
43、 ASAAC Communication Stack The ASAAC Communication shall 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
44、.1.2 VC Inter-process communication is based on VCs. VCs 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
45、 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 data onto a
46、 particular VC. Similarly, a receiving process has no knowledge of the sending process; it merely receives certain data from certain VCs. prEN 4660-005:2009 (E) 28 The source and destination processes, the data items to be transmitted between them, and the VCs, over which they are transmitted, are d
47、efined during system design. During run-time this information is provided by the RTBP. Consequently, for a given system configuration, the set of VCs used is fixed and provides a reference against which audit data can be generated. Each VC shall be associated with a specific message. Therefore, the
48、following properties of messages are also associated with the VC: Data representation: one message shall be described in the blueprints, Security (encryption, decryption): the VC is marked or not, Modularity: an application must be seen as a message server. During application design, there is no kno
49、wledge about how many users shall be supposed to receive the message. 4.2.1.3 TC The basic communication link offered by the NII is the Transfer Connection (TC). Data transfer via TCs has the following properties: The TC is unidirectional. The OS manages the TC in terms of creation, deletion and routing. A TC shall be capable to be used by either one or many VCs A TC supports streaming communication mode. 4.2.1.4 NC The ASAAC Standard does not e
