ASD-STAN PREN 4660-005-2018 Aerospace series - Modular and Open Avionics Architectures - Part 005 Software (Edition P 2).pdf

1、 ASD-STAN STANDARD NORME ASD-STAN ASD-STAN NORM ASD-STAN prEN 4660-005 Edition P2 2018-04 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATION Rue Montoyer 10 - 1000 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.org ICS: Descriptors: ENGLI

2、SH VERSION Aerospace series Modular and Open Avionics Architectures Part 005: Software Luft- und Raumfahrt Modulare und offene Avionikarchitekturen Teil 005: Software Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 005 : Software This “Aerospace Series“ Prestandard has been d

3、rawn 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 has been technically approved by the experts of the concerned Domain following member comments. Subsequent

4、 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 standard. After examination and review by users and formal agreement of ASD-STAN, the ASD-STAN prEN will

5、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 the EN at national level by giving the EN the status of a national standard and by withd

6、rawing any national standards conflicting with the EN. ASD-STAN Technical Committee approves that: “This document is published by ASD-STAN for the needs of the European Aerospace Industry. The use of this standard is entirely voluntary, and its applicability and suitability for any particular use, i

7、ncluding any patent infringement arising therefrom, is the sole responsibility of the user.” ASD-STAN reviews each standard and technical report at least every five years at which time it may be revised, reaffirmed, stabilized or cancelled. ASD-STAN invites you to send your written comments or any s

8、uggestions that may arise. All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of ASD-STAN. Order details: E-mail

9、: salesasd-stan.org Web address: http:/www.asd-stan.org/ Edition approved for publication 1stApril 2018 Comments should be sent within six months after the date of publication to ASD-STAN General Domain prEN 4660-005:2018 (E) 2 Contents Page Introduction 5 1 Scope 6 1.1 General scope . 6 1.2 Softwar

10、e Architecture Overview . 6 1.3 Software Architectural Components 6 1.3.1 General 6 1.3.2 Functional Applications 7 1.3.3 Application Management (AM) 7 1.3.4 Operating System (OS) 7 1.3.5 Generic System Management (GSM). 7 1.3.6 Run-Time Blueprints (RTBP) 8 1.3.7 Module Support Layer (MSL) 8 1.3.8 A

11、pplication to OS Interface (APOS) . 8 1.3.9 Module Support to OS Interface (MOS) 8 1.3.10 System Management to Blueprints Interface (SMBP) 8 1.3.11 System Management to OS Interface (SMOS) 8 1.3.12 OS Logical Interface (OLI) 8 1.3.13 GSM Logical Interface (GLI) . 8 1.3.14 System Management Logical I

12、nterface (SMLI) . 8 1.3.15 Module Logical Interface (MLI) 8 2 Normative references 9 3 Terms, definitions and abbreviations 10 3.1 Terms and definitions 10 3.2 Abbreviations 11 4 System Functions 13 4.1 System Management Function. 13 4.1.1 General . 13 4.1.2 GSM Function . 15 4.1.3 AM Function . 17

13、4.1.4 Error Handling 18 4.1.5 Built-In Test 18 4.2 Communication . 20 4.2.1 MOAA Communication Model 20 4.2.2 Types of Data Transfer . 23 4.2.3 Communication Configuration 23 4.2.4 Communication Protocols . 24 4.2.5 Multicast 27 4.2.6 Distributed Multicast 29 4.2.7 Streaming 32 4.2.8 Data Representa

14、tion . 33 4.3 Security Management . 38 4.3.1 Application Security Management . 38 4.3.2 Generic Security Management . 39 4.3.3 Encryption/Decryption and Authentication 40 prEN 4660-005:2018 (E) 3 4.3.4 Security Audit . 40 4.3.5 Security Reference Monitoring 41 4.4 Module Management . 41 4.5 Mass Mem

15、ory Management 42 4.5.1 Overview 42 4.5.2 MMM Local File Management . 42 4.5.3 Application File Access . 42 4.5.4 CFM Download . 43 4.5.5 Application Downloading 44 4.6 Graphics Management 45 4.7 Power Management . 45 4.7.1 GSM Controlled Solution 46 4.7.2 MLI Controlled Solution 47 4.8 Network Mana

16、gement . 47 4.8.1 Network Definition 47 4.8.2 Network Configuration . 47 4.8.3 Network Health Monitoring 48 4.8.4 Network Technology Transparency 48 4.9 Time Management 49 4.9.1 Time reference 49 4.9.2 Clock Hierarchy . 50 4.9.3 Clock Configuration . 52 4.9.4 Clock Management . 52 5 Software Archite

17、cture Definition 53 5.1 MSL . 54 5.1.1 MSL Module Management 54 5.1.2 MSL Communication Capability . 55 5.1.3 Resident Software . 58 5.2 OSL . 59 5.2.1 GSM 59 5.2.2 OS Functions . 66 5.3 RTBP 82 5.3.1 Overview 82 5.3.2 RTBP tree . 83 5.3.3 SMBP Services to Access the RTBP Tables . 84 5.4 Application

18、 Layer 85 5.4.1 Language Considerations . 85 5.4.2 Application Error Handling . 85 6 Direct Interfaces Definitions 86 6.1 APOS 86 6.2 MOS 90 6.2.1 Generic MOS 91 6.2.2 Specific Services . 131 6.2.3 MOS Bespoke Extension Services . 146 6.3 SMBP . 163 6.3.1 RTBP Tree Grammar 164 6.3.2 Services for Ret

19、rieving Tables 170 6.4 SMOS . 180 6.4.1 Process and Thread Management Services 181 6.4.2 Fault Management Services . 182 6.4.3 VC Configuration Services . 185 6.4.4 Network Configuration Services 191 prEN 4660-005:2018 (E) 4 6.4.5 Security Management Services 195 6.4.6 Built-In Test Management Servi

20、ces . 199 6.4.7 CFM Information Services . 204 6.4.8 CFM Resources Management Services 206 6.4.9 Time Configuration Services 209 6.4.10 Logging Management Services 210 7 Logical Interfaces Definitions 213 7.1 OLI 214 7.1.1 VC Header 214 7.1.2 OLI Services 214 7.2 GLI 214 7.2.1 GLI Representation 214

21、 7.2.2 GLI Services 214 7.3 SMLI . 221 7.3.1 SMLI Representation . 221 7.3.2 SMLI Services . 221 7.4 MLI . 229 7.4.1 TC Header 229 7.4.2 MLI Services . 229 7.4.3 Protocol . 250 8 Data Type Definitions . 255 8.1 IDL 255 8.1.1 General . 255 8.1.2 Basic Types . 255 8.1.3 Name Spaces . 256 8.1.4 Limitat

22、ions 256 8.2 Data Types 256 9 Tailoring 280 (normative) RTBP XML Schema 288 Annex AA.1 MOAA Types . 288 A.2 MOAA Type Extensions 294 A.3 MOAA Runtime Blueprints 297 (informative) Standard Evolution Form 311 Annex BprEN 4660-005:2018 (E) 5 Introduction The purpose of this MOAA standard is to define a

23、 set of open architecture standards, concepts identification, masking, filtering, and localisation of errors; provision of security related services. The System Management is comprised of two functions located on the application and OSLs of the IMA Three-Layer-Stack model (Figure 3): the Application

24、 Management function (AM): Aircraft dependent, HW independent; the GSM function (GSM): Aircraft independent, HW independent. prEN 4660-005:2018 (E) 14 The underlying principles of this architecture are the separation between hardware and aircraft dependent layers and the separation between avionics

25、functions represented by functional applications and system management functions. The System Management function is organized hierarchically on three level types (Figure 4) covering the following functionalities: Aircraft (AC) level; Integration Area (IA) level; Resource Element (RE) level. Figure 4

26、 Hierarchical Organisation of the System Management Each level has dedicated characteristics: AC Level: The AC level is a single system management entity responsible for controlling/monitoring the entire IMA core. IA Level: The IA level is a logical grouping of closely integrated functional applicat

27、ions with their resources. This grouping need not be static, but may be created and deleted dynamically during a mission. Each IA controls one or more REs. IAs may internally be organised hierarchically, i.e. a system may include one or more IA levels. In this case, the lowest-level IA must control

28、one or more PEs. A system may be designed so that it does not include an IA level. In this case, there is one AC level, and one or more RE levels. prEN 4660-005:2018 (E) 15 RE Level: The resource element is the lowest addressable level in the system management hierarchy responsible for managing the

29、functionality of a single Processing Element (PE). 4.1.2 GSM Function The GSM function GSM is responsible for the management and control of all resources and management of the IMA system behaviour via the use of RTBP (see 5.3). Figure 5 GSM Decomposition for RE-Management (Example) Functions: The GS

30、M comprises four functions: Configuration Management: Set-up of the initial configuration, reconfiguration management. Health Monitoring: Monitoring of the health status, error collection, filtering, and transmission to the FM. Fault Management: Masking, filtering, and localisation of faults includi

31、ng the processing of corrective actions. Security Management: Implementation of the system security policy: Authentication, decryption, and encryption. Hierarchical Organisation: The following figures illustrate possible mappings of resources to the system management hierarchy: RE management (Figure

32、 5): An AC manager controlling 2 IA managers IA1 and IA4; IA1 controlling the IA managers IA2 and IA3; IA2, IA3, and IA4 each controlling 2 REs prEN 4660-005:2018 (E) 16 Figure 6 IA Application Control (Example) Application configuration control (Figure 6): An AC manager controlling IA1 and IA4; IA1

33、 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. Figure 7 GSM Decomposition for Module Management (Example) Application configuration control (Figure 7): An AC manager

34、 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. Configuration Data: The configuration data is obtained from the RTBP via SMBP. The reconf

35、iguration is defined through dedicated sequences obtained via SMBP. prEN 4660-005:2018 (E) 17 Initialisation and Shut-Down: Initialisation and shut-down is performed on three different levels: application; system; module. 4.1.3 AM Function The AM function is responsible for the management and contro

36、l 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 located on the AC- and IA-levels, as the RE level is resourc

37、e-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: Figure 8 Hierarchical Organisation of the AM (Example) Internal Interfaces: The standardised intern

38、al 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. prEN 4660-005:2018 (E) 18 External Interfaces: There are no standardised external interfaces of the AM. All external interfaces are app

39、lication-dependent. 4.1.4 Error Handling MOAA 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 (6.1). However, it is possible at run-time for an APOS se

40、rvice not to perform correctly and to 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 has been created). In either case the fault is handled throug

41、h 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 management function. In handling the error, the fault manageme

42、nt 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 thread. The error information shall be accessible to the applic

43、ation 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 out. In this case, the application calling a

44、service shall be informed by means of a return value. 4.1.5 Built-In Test 4.1.5.1 General 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 the module. There are three d

45、ifferent 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: get PBIT Result: Retrieves th

46、e 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 result. prEN 4660-005:2018

47、(E) 19 4.1.5.2 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

48、a GSM on a controlling module via the MLI. It is also available via a MOS/SMOS call to the local GSM. 4.1.5.3 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 p

49、rocessor 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: call-back; polled, either as part of the calling mechanism or as a separate call. The various combinations of CBIT behaviour are described below: Table 2 CBIT Modes Run method Result Method Behaviour Autonomous Call-back CBIT runs autonomously and does not require control from outside the MSL. When a test