NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

STANAG No. 4626

Part II
Draft 1

NORTH ATLANTIC TREATY ORGANIZATION

(NATO)

MILITARY AGENCY FOR STANDARDIZATION

(MAS)

STANDARDIZATION AGREEMENT
(STANAG)

SUBJECT: MODULAR AND OPEN AVIONICS ARCHITECTURES

PART II - SOFTWARE

Promulgated on

NATO UNCLASSIFIED
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NORTH ATLANTIC TREATY ORGANIZATION

ORGANISATION DU TRAITE DE L’ATLANTIQUE NORD

MILITARY AGENCY FOR STANDARDIZATION (MAS)

BUREAU MILITAIRE DE STANDARDISATION (BMS)
1110 BRUSSELS

Tel: 707.43.09

….. MAS …..

STANAG 4626 (DRAFT 1) – MODULAR AND OPEN AVIONICS ARCHITECTURES

PART II: SOFTWARE

1. The enclosed NATO Standardization Agreement is herewith promulgated for ratification.

ACTION BY NATIONAL STAFFS

2 National staffs are requested to examine page iii of the STANAG and, if they have not
already done so, advise the …… Division of their intention regarding its ratification and
implementation.

Enclosure:
STANAG 4626 Part II (Draft 1)

NATO UNCLASSIFIED i
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

RECORD OF AMENDMENTS

No. Reference/date of Date Signature

amendment entered

EXPLANATORY NOTES

AGREEMENT

1. This NATO Standardization Agreement (STANAG) is promulgated by the Chairman MAS

under the authority vested in him by the NATO Military Committee.

2. No departure may be made from the agreement without consultation with the tasking
authority. Nations may propose changes at any time to the tasking authority where they will be
processed in the same manner as the original agreement.

3. Ratifying nations have agreed the national orders, manuals and instructions implementing
this STANAG will include a reference to the STANAG number for purposes of identification.

DEFINITIONS

4. Ratification is “In NATO Standardization, the fulfillment by which a member nation formally
accepts, with or without reservation, the content of a Standardization Agreement” (AAP-6).

5. Implementation is “In NATO Standardization, the fulfillment by a member nation of its

obligations as specified in a Standardization Agreement (AAP-6).

6. Reservation is “In NATO Standardization, the stated qualification by a member nation that
describes the part of a Standardization Agreement that it will not implement or will implement only with
limitations (AAP-6).

RATIFICATION, IMPLEMENTATION AND RESERVATIONS

7. Page iii gives the details of ratification and implementation of this agreement. If no details are
shown it signifies that the nation has not yet notified the tasking authority of it intentions. Page iv (and
subsequent) gives details of reservations and proprietary rights that have been stated.

FEEDBACK

8. Any comments concerning this publication should be directed to NATO/MAS – Bvd Leopold
III – 1110 Brussels - BE

NATO UNCLASSIFIED ii
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

RATIFICATION AND IMPLEMENTATION DETAILS

STADE DE RATIFICATION ET DE MISE EN APPLICATION

IMPLEMENTATION / MISE EN APPLICATION

N NATIONAL
INTENDED DATE OF DATE IMPLEMENTATION
A IMPLEMENTING
NATIONAL RATIFICATION IMPLEMENTATION / WAS ACHIEVED /
T DOCUMENT /
I REFERENCE DE LA DATE PREVUE POUR MISE DATE REELLE DE MISE EN
DOCUMENT
O RATIFICATION NATIONALE EN APPLICATION APPLICATION
NATIONAL DE MISE
N
EN APPLICIATION NAVY ARMY AIR NAVY ARMY AIR
MER TERRE MER TERRE

BE

CA

CZ

DA

FR

GE

HU

IT

LU

NL

NO

PO

SP

TU

UK

US

NATO UNCLASSIFIED iii

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

RESERVATIONS

RESERVES

NATO UNCLASSIFIED iv
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NAVY / ARMY / AIR

NATO STANDARDIZATION AGREEMENT

(STANAG)

MODULAR AND OPEN AVIONICS ARCHITECTURE

PART II: SOFTWARE

Related Documents:
(a) STANAG 4626 Part I – Architecture

(b) STANAG 4626 Part III – Common Functional Modules

(c) STANAG 4626 Part IV – Packaging

(d) STANAG 4626 Part V – Networks and Communication

(e) STANAG 4626 Part VI – Guidelines for System Issues

• Vol. 1: System Management
• Vol. 2: Fault Management
• Vol. 3: System Initialisation and Shutdown
• Vol. 4: System Configuration/Reconfiguration
• Vol. 5: Time Management
• Vol. 6: Security Aspects
• Vol. 7: Safety

NATO UNCLASSIFIED 1
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AIM

1. The aim of this agreement is to define and standardize essential technical characteristics
which shall be incorporated in the design of avionics architectures.

AGREEMENT

2. Participating nations agree to adopt the avionic architectures of future aircraft developments
and upgrades to the Standards and Guidelines of open avionics architectures as described in this
STANAG.

DEFINITIONS
3. The definition of terms and abbreviations used in this Agreement are given in each Part of
the Standard.

GENERAL

4. t.b.d.

DETAILS OF AGREEMENT

5. The details of the agreement are given as follows:

• in Part I: Architecture Standard and Annex “Rationale Report for Architecture
Standards”
• in Part II: Software and Annex “Rationale Report for Architecture Software Standards”
• in Part III: Common Functional Modules and Annex “Rationale Report for Common
Functional Modules Standards”
• in Part IV: Packaging and Annex “Rationale Report for Packaging Standards”
• in Part V: Networks and Communication and Annex “Rationale Report for
Communications / Network Standards”
• in Part VI: Guidelines for System Issues consisting of:
• Vol. 1: System Management
• Vol. 2: Fault Management
• Vol. 3: System Initialisation and Shutdown
• Vol. 4: System Configuration/Reconfiguration
• Vol. 5: Time Management
• Vol. 6: Security Aspects
• Vol. 7: Safety

each Part being published separately as STANAG 4626 (Part I), STANAG 4626 (Part II), STANAG
4626 (Part III), STANAG 4626 (Part IV), STANAG 4626 (Part V) and STANAG 4626 (Part VI).

NATO UNCLASSIFIED 2
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Study n°: Draft n°: I02 Date: 05/04/04 Step n°:

ENGLISH VERSION

ASAAC Phase II

Final Draft of Proposed Standards for Software

Final proposition des standards pour les Entgültiger Entwurf des Standards für Software
software

NATO UNCLASSIFIED 1
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table of Contents

0 Introduction .............................................................................................................................. 7
0.1 Purpose .................................................................................................................................... 7
0.2 Document Structure ................................................................................................................ 8
1 Scope ........................................................................................................................................ 9
1.1 Software Architecture Overview ............................................................................................ 9
1.2 Software Architectural Components ..................................................................................... 9
1.2.1 Functional Applications ........................................................................................................ 10
1.2.2 Application Management (AM) ............................................................................................. 10
1.2.3 Operating System (OS) ......................................................................................................... 10
1.2.4 Generic System Management (GSM) ................................................................................... 10
1.2.5 Run-Time Blueprints (RTBP) ................................................................................................ 11
1.2.6 Module Support Layer (MSL) ............................................................................................... 11
1.2.7 Application to OS Interface (APOS) ..................................................................................... 11
1.2.8 Module Support to OS Interface (MOS) ............................................................................... 11
1.2.9 System Management to Blueprints Interface (SMBP) ....................................................... 11
1.2.10 System Management to OS Interface (SMOS) .................................................................... 11
1.2.11 OS Logical Interface (OLI) .................................................................................................... 11
1.2.12 GSM Logical Interface (GLI) ................................................................................................. 11
1.2.13 System Management Logical Interface (SMLI) ................................................................... 12
1.2.14 Module Logical Interface (MLI) ............................................................................................. 12
2 Normative References........................................................................................................... 13
3 Terms, Definitions and Abbreviations................................................................................. 14
3.1 Terms and Definitions ........................................................................................................... 14
3.2 Abbreviations ......................................................................................................................... 14
4 System Functions .................................................................................................................. 18
4.1 System Management Function ............................................................................................ 18
4.1.1 GSM Function ........................................................................................................................ 19
4.1.2 AM Function ........................................................................................................................... 22
4.1.3 Error Handling ....................................................................................................................... 23
4.1.4 Built-In Test ............................................................................................................................ 23
4.2 Communication ..................................................................................................................... 25
4.2.1 ASAAC Communication Model ............................................................................................ 25
4.2.2 Types of Data Transfer.......................................................................................................... 27
4.2.3 Communication Configuration ............................................................................................. 27
4.2.4 Communication Protocols .................................................................................................... 28
4.2.5 Multicast ................................................................................................................................. 31
4.2.6 Distributed Multicast ............................................................................................................. 33
4.2.7 Streaming ............................................................................................................................... 37
4.2.8 Data Representation.............................................................................................................. 37
4.3 Security Management ........................................................................................................... 42
4.3.1 Application Security Management ....................................................................................... 44
4.3.2 Generic Security Management ............................................................................................. 44
4.3.3 Encryption/Decryption and Authentication ........................................................................ 45
4.3.4 Security Audit ........................................................................................................................ 46
4.3.5 Security Reference Monitoring ............................................................................................ 46
4.4 Module Management ............................................................................................................. 46
4.5 Mass Memory Management .................................................................................................. 47
4.5.1 Overview ................................................................................................................................. 47
4.5.2 MMM Local File Management ............................................................................................... 47
4.5.3 Application File Access ........................................................................................................ 48
4.5.4 CFM Download ....................................................................................................................... 48
4.5.5 Application Downloading ..................................................................................................... 50

NATO UNCLASSIFIED 1
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

4.6 Graphics Management .......................................................................................................... 51

4.7 Power Management ............................................................................................................... 53
4.7.1 Application Controlled Solution .......................................................................................... 53
4.7.2 GSM Controlled Solution ...................................................................................................... 54
4.7.3 MLI Controlled Solution ........................................................................................................ 55
4.8 Network Management ........................................................................................................... 56
4.8.1 Network Definition ................................................................................................................. 56
4.8.2 Network Configuration .......................................................................................................... 56
4.8.3 Network Health Monitoring ................................................................................................... 58
4.8.4 Network Technology Transparency .................................................................................... 58
4.9 Time Management ................................................................................................................. 59
4.9.1 Time References .................................................................................................................... 59
4.9.2 Clock Hierarchy ..................................................................................................................... 60
4.9.3 Clock Configuration .............................................................................................................. 61
4.9.4 Clock Management ................................................................................................................ 62
5 Software Architecture Definition ......................................................................................... 63
5.1 MSL ......................................................................................................................................... 64
5.1.1 MSL Module Management .................................................................................................... 64
5.1.2 MSL Communication Capability .......................................................................................... 65
5.1.3 Resident Software ................................................................................................................. 69
5.2 OSL ......................................................................................................................................... 69
5.2.1 GSM......................................................................................................................................... 69
5.2.2 OS Functions ......................................................................................................................... 76
5.3 RTBP ..................................................................................................................................... 103
5.3.1 Overview ............................................................................................................................... 103
5.3.2 RTBP tree ............................................................................................................................. 103
5.3.3 SMBP Services to Access the RTBP Tables .................................................................... 104
5.4 Application Layer ................................................................................................................ 105
5.4.1 Process Model ..................................................................................................................... 105
5.4.2 Resource Management ....................................................................................................... 106
5.4.3 Thread Properties ................................................................................................................ 107
5.4.4 Safety Considerations......................................................................................................... 107
5.4.5 Language Considerations .................................................................................................. 111
5.4.6 Application Error Handling ................................................................................................. 111
6 Direct Interfaces Definitions ............................................................................................... 113
6.1 APOS..................................................................................................................................... 113
6.1.1 Thread Management Services ............................................................................................ 116
6.1.2 Time Management Services ............................................................................................... 124
6.1.3 Semaphore Synchronisation Services .............................................................................. 127
6.1.4 Event Synchronisation Services ........................................................................................ 134
6.1.5 Error Handling Services...................................................................................................... 140
6.1.6 Debugging Services ............................................................................................................ 143
6.1.7 Communication Services ................................................................................................... 145
6.1.8 File Handling Services ........................................................................................................ 159
6.1.9 Power Conversion Services ............................................................................................... 175
6.2 MOS....................................................................................................................................... 177
6.2.1 Generic MOS ........................................................................................................................ 178
6.2.2 Specific Services ................................................................................................................. 220
6.2.3 MOS Bespoke Extension Services .................................................................................... 235
6.3 SMBP .................................................................................................................................... 252
6.3.1 RTBP Tree Grammar ........................................................................................................... 252
6.3.2 Services for Retrieving Tables ........................................................................................... 264
6.4 SMOS .................................................................................................................................... 274
6.4.1 Process and Thread Management Services ..................................................................... 276
6.4.2 Fault Management Services ............................................................................................... 282
6.4.3 VC Configuration Services ................................................................................................. 285
6.4.4 Network Configuration Services ........................................................................................ 291
6.4.5 Security Management Services ......................................................................................... 295
6.4.6 Built-In Test Management Services ................................................................................... 300
6.4.7 CFM Information Services .................................................................................................. 304

NATO UNCLASSIFIED 2
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

6.4.8 CFM Resources Management Services ............................................................................ 306

6.4.9 Time Configuration Services .............................................................................................. 310
6.4.10 Logging Management Services ......................................................................................... 312
7 Logical Interfaces Definitions ............................................................................................ 316
7.1 OLI ......................................................................................................................................... 316
7.1.1 VC Header ............................................................................................................................ 316
7.1.2 OLI Services ......................................................................................................................... 316
7.2 GLI ......................................................................................................................................... 322
7.2.1 GLI Representation ............................................................................................................. 322
7.2.2 GLI Services ......................................................................................................................... 322
7.3 SMLI ...................................................................................................................................... 343
7.3.1 SMLI Representation ........................................................................................................... 344
7.3.2 SMLI Services ...................................................................................................................... 344
7.4 MLI......................................................................................................................................... 351
7.4.1 TC Header ............................................................................................................................. 351
7.4.2 MLI Services ......................................................................................................................... 351
7.4.3 Protocol ................................................................................................................................ 395
8 Data Type Definitions .......................................................................................................... 407
8.1 IDL ......................................................................................................................................... 407
8.1.1 Basic Types .......................................................................................................................... 407
8.1.2 Name Spaces ....................................................................................................................... 407
8.1.3 Limitations ........................................................................................................................... 408
8.2 Data Types ........................................................................................................................... 408
9 Tailoring ............................................................................................................................... 450
Annex A AGL ......................................................................................................................... 460
A.1. The Concept ......................................................................................................................... 460
A.2. Graphical Command Set ..................................................................................................... 460
A.2.1. Overview ............................................................................................................................... 460
A.2.2. Command Listings .............................................................................................................. 461
A.2.3. Auxiliary Library (AL) Definition ........................................................................................ 465
A.2.4. Video Library (VL) Definition .............................................................................................. 466
A.2.5. Texture Mapping Constraints ............................................................................................. 467
A.2.6. Display Frame and Synchronisation ................................................................................. 468
A.2.7. Command Responses and Delays ..................................................................................... 468

List of Figures
Figure 1 - ASAAC Standard Documentation Hierarchy .................................................................... 7
Figure 2 - ASAAC Three Layer Software Architecture ..................................................................... 9
Figure 3 - The Software Architecture Model .................................................................................... 10
Figure 4 - Hierarchical Organisation of the System Management ................................................ 19
Figure 5 - GSM Decomposition for RE-Management (Example).................................................... 20
Figure 6 - IA Application Control (Example) .................................................................................... 21
Figure 7 - GSM Decomposition for Module Management (Example) ............................................ 21
Figure 8 - Hierarchical Organisation of the AM (Example) ............................................................. 22
Figure 9 - The ASAAC Communication Stack ................................................................................. 25
Figure 10 - Types of Data Transfer ................................................................................................... 27
Figure 11 - Communication Concept ................................................................................................ 28
Figure 12 - Between AL Communication Routing ........................................................................... 29
Figure 13 - ASAAC Message in BMC Data Transfer ....................................................................... 31
Figure 14- Multicast Scheme With a Single TC ............................................................................... 32
Figure 15 - Multicast Scheme With Multiple Simple TC’s ............................................................... 33
Figure 16 - Data Parallelism............................................................................................................... 34
Figure 17 - Corner Turn ...................................................................................................................... 34
Figure 18 - Corner Turn in Three Dimensions ................................................................................. 35
Figure 19 - Illustration of the Involved Services in DSP1 ............................................................... 36

NATO UNCLASSIFIED 3
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 20 - Data Representation ....................................................................................................... 38

Figure 21 - GSM Interfaces ................................................................................................................ 43
Figure 22 - Main Security Related Architectural Components ...................................................... 44
Figure 23 - VC transferring Data Requiring Encryption & Decryption .......................................... 45
Figure 24 - File Handling by a Remote Application ........................................................................ 48
Figure 25 - MMM Download onto a CFM with only the MSL ........................................................... 49
Figure 26 - CFM Download onto a CFM with only the MSL ............................................................ 50
Figure 27 - Application Download .................................................................................................... 51
Figure 28 - Graphics Concept ........................................................................................................... 52
Figure 29 - Graphics Standard .......................................................................................................... 52
Figure 30 - Application Control ......................................................................................................... 54
Figure 31 - PCM Management (Example) ......................................................................................... 55
Figure 32 - Configuration of a NSM .................................................................................................. 57
Figure 33 - Network Configuration Message Format ...................................................................... 58
Figure 34 - Clock Hierarchy in an ASAAC System .......................................................................... 61
Figure 35 - Software Architecture ..................................................................................................... 63
Figure 36 - ASAAC Software Stack on a CFM ................................................................................. 64
Figure 37 - GSM Logical Interface .................................................................................................... 70
Figure 38 - GSM: External Interfaces ................................................................................................ 70
Figure 39 - Thread State Transition Diagram with sample APOS services .................................. 77
Figure 40 - Process State Diagram ................................................................................................... 82
Figure 41 - Example for a 1 to N FIFO .............................................................................................. 85
Figure 42 - Example for a 1 to N LIFO .............................................................................................. 85
Figure 43 - OS Error Handling of an Application Error ................................................................... 93
Figure 44 - OS Error Handling of an MSL Error Due to a Return of a MOS Service .................... 94
Figure 45 - OS Error Handling of an MSL Error Due to a CBIT Status .......................................... 95
Figure 46 - The OLI ............................................................................................................................. 97
Figure 47 - Decomposition for OLI ................................................................................................... 97
Figure 48 - RTBP Tree Concept ...................................................................................................... 103
Figure 49 - Relation of Processes and Threads and VC’s ............................................................ 106
Figure 50 - Software Architecture Model - Three-Layer Stack (TLS) .......................................... 177
Figure 51 - MOS Software Architecture Model .............................................................................. 177
Figure 52 - sendFragmentedTransfer Data Buffer Description ................................................... 231
Figure 53 - Splitting of Incoming Data with receiveFragmentedTransfer ................................... 233
Figure 54 - Different Step Sizes with Fragmented Transfers ....................................................... 233
Figure 55 - Root Definition............................................................................................................... 255
Figure 56 - Function Set Definition ................................................................................................. 256
Figure 57 - Configuration Set Definition ........................................................................................ 257
Figure 58 - Process Set Definition .................................................................................................. 258
Figure 59 - VC Set Definition ........................................................................................................... 259
Figure 60 - TC Set Definition ........................................................................................................... 260
Figure 61 - CFM Set Definition ........................................................................................................ 261
Figure 62 - PE Set Definition ........................................................................................................... 262
Figure 63 - Clock Set Definition ...................................................................................................... 262
Figure 64 - State Machine Set Definition ........................................................................................ 263
Figure 65 - General VC Message Format ....................................................................................... 316
Figure 66 - File Reading Protocol ................................................................................................... 318
Figure 67 - Remote MLI Download Management Protocol ........................................................... 319
Figure 68 - General SMLI Message Format .................................................................................... 345
Figure 69 - General TC Message Format........................................................................................ 351
Figure 70 - General MLI Message Format ...................................................................................... 351
Figure 71 - Optional Parameter Element Format ........................................................................... 352
Figure 72 - Request PBIT Result Format........................................................................................ 353
Figure 73 - Reply PBIT Result Format ............................................................................................ 354
Figure 74 - Request CFM Status Format ........................................................................................ 355
Figure 75 - Reply CFM Status Format ............................................................................................ 355
Figure 76 - Request CFM Info Format ............................................................................................ 359
Figure 77 - Reply CFM Info Format ................................................................................................. 359
Figure 78 - Test Message Format ................................................................................................... 360
Figure 79 - Test Message Acknowledge Format ........................................................................... 360
Figure 80 - Request IBIT Start Format ............................................................................................ 361

NATO UNCLASSIFIED 4
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 81 - Reply IBIT Start Format ................................................................................................ 361

Figure 82 - Request IBIT Result Format ......................................................................................... 362
Figure 83 - Reply IBIT Result Format ............................................................................................. 362
Figure 84 - Load Image Format ....................................................................................................... 363
Figure 85 - Load Image Acknowledge Format ............................................................................... 365
Figure 86 - Load Routing Table Format ......................................................................................... 367
Figure 87 - Load Routing Table Acknowledge Format ................................................................. 372
Figure 88 - Load Time Configuration Format ................................................................................ 374
Figure 89 - Load Time Configuration Acknowledge Format ....................................................... 378
Figure 90 - Request AGT Format .................................................................................................... 379
Figure 91 - Reply AGT Format ......................................................................................................... 379
Figure 92 - Ready_For_ALT_Synchro Format ............................................................................... 380
Figure 93 - Start_ALT_Synchro Format ......................................................................................... 381
Figure 94 - Request ALT Format ..................................................................................................... 381
Figure 95 - Reply ALT Format ......................................................................................................... 382
Figure 96 - Request AGT ALT Format ............................................................................................ 383
Figure 97 - Reply AGT ALT Format ................................................................................................. 383
Figure 98 - Load Network Configuration Format .......................................................................... 384
Figure 99 – NSM Switch Command Format ................................................................................... 386
Figure 100 – NSM Connection Command Format ......................................................................... 387
Figure 101 – NSM Reset Command Format ................................................................................... 387
Figure 102 – NSM Execute Command Format ............................................................................... 387
Figure 103 - Load Network Configuration Acknowledge Format ................................................ 387
Figure 104 - Load Network Configuration Format ........................................................................ 388
Figure 105 – Reply Network Status Format ................................................................................... 389
Figure 106 - Load Power Switches Configuration Format ........................................................... 391
Figure 107 – PCM Switch Command Format ................................................................................. 392
Figure 108 – Power Switch Command Format .............................................................................. 392
Figure 109 – Power Switch Reset Format ...................................................................................... 392
Figure 110 – Power Switch Configuration Acknowledge Format ................................................ 393
Figure 111 – Request Power Switch Status Format ..................................................................... 394
Figure 112 – Reply Power Switches Status Format ...................................................................... 394
Figure 113 - General CFM Resource Management Protocol ........................................................ 397
Figure 114 - General Download Management Protocol ................................................................ 400
Figure 115 - General Time Management Protocol ......................................................................... 402
Figure 116 - Load Network Configuration Format ........................................................................ 408
Figure A.1 - Graphics Concept ........................................................................................................ 460

List of Tables
Table 1 - Software Layer Independence ............................................................................................. 9
Table 2 - CBIT Modes ......................................................................................................................... 24
Table 3 - Routing Information and Data Transfer ............................................................................ 31
Table 4 - IDL Primitive Types ............................................................................................................ 40
Table 5 - IDL Constructive Types ...................................................................................................... 42
Table 6 - Power Switching Services ................................................................................................. 53
Table 7 - Layers, Process Classes, and Standardised Interfaces ................................................. 63
Table 8 - List of SMOS Services for RE-CM ..................................................................................... 71
Table 9 - List of SMOS Services for RE-HM ..................................................................................... 72
Table 10 - List of SMOS Services for RE-FM ................................................................................... 73
Table 11 - List of SMOS Services for RE-SM ................................................................................... 73
Table 12 - List of SMOS Services for IA-CM .................................................................................... 74
Table 13 - List of SMOS Services for IA-FM ..................................................................................... 75
Table 14 - List of SMOS Services for AC-FM ................................................................................... 76
Table 15 – Transition of Thread States ............................................................................................ 78
Table 16 – Condition of State Transition.......................................................................................... 78
Table 17 - Properties of Time Services ............................................................................................ 89
Table 18 - Resource Parameters of Basic Resource Entities ...................................................... 107
Table 19 - Criticality Classes of APOS Services ........................................................................... 108

NATO UNCLASSIFIED 5
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table 20 - Safety Restriction Definitions ........................................................................................ 110

Table 21 - APOS Services ................................................................................................................ 113
Table 22 – APOS File Seek Modes .................................................................................................. 169
Table 23 - Core MOS Services ......................................................................................................... 178
Table 24 – Specific Board MOS Services ....................................................................................... 220
Table 25 - MOS Bespoke Extension Services................................................................................ 235
Table 26 - Overview of All SMBP Services..................................................................................... 252
Table 27 - Identifiers Described as ID_ITEM .................................................................................. 253
Table 28 - Mapping of EBNF Specification with RTBP Concept .................................................. 254
Table 29 - Overview of all SMOS Services ..................................................................................... 274
Table 30 – MLI Download Types ..................................................................................................... 307
Table 31 - OLI Services .................................................................................................................... 320
Table 32 - GLI Services List ............................................................................................................. 323
Table 33 - SMLI Services List .......................................................................................................... 344
Table 34 - MLI Services .................................................................................................................... 352
Table 35 - Reply PBIT Status Payload Field Definition ................................................................. 354
Table 36 - Reply CFM Status Payload Field Definition ................................................................. 355
Table 37 - GENERIC_CFM Specific Extension to Payload Information ...................................... 356
Table 38 - NOT_GENERIC_CFM Specific Extension to Payload Information ............................. 358
Table 39 - Reply CFM Info Payload Field Definition ...................................................................... 359
Table 40 - Reply IBIT Status Payload Field Definition .................................................................. 361
Table 41 - Reply IBIT Result Payload Field Definition .................................................................. 362
Table 42 - Load Image Payload Field Definition ............................................................................ 363
Table 43 - Load Image Acknowledge Payload Field Definition .................................................... 365
Table 44 - Load Routing Table Payload Field Definition .............................................................. 367
Table 45 - Load Routing Table Data Definition .............................................................................. 368
Table 46 - Data Definition for Interface Configuration .................................................................. 369
Table 47 - Data Definition for Transfer Configuration .................................................................. 370
Table 48 - Data Definition for Protocol Configuration .................................................................. 371
Table 49 - Data Definition for Destroy Transfer ............................................................................. 372
Table 50 - Load Routing Table Acknowledge Payload Field Definition ...................................... 372
Table 51 - Load Time Configuration Payload Field Definition ..................................................... 374
Table 52 - Load Time Configuration Data Definition ..................................................................... 375
Table 53 - Data Definition for Clock Configuration ....................................................................... 375
Table 54 - Data Definition for Federated Clock Configuration ..................................................... 377
Table 55 - Load Time Configuration Acknowledge Payload Field Definition ............................. 378
Table 56 - Reply AGT Payload Field Definition.............................................................................. 379
Table 57 - Start_ALT_Synchro Payload Field Definition .............................................................. 381
Table 58 - Reply ALT Payload Field Definition .............................................................................. 382
Table 59 - Reply AGT ALT Payload Field Definition ..................................................................... 383
Table 60 - Load Network Configuration Payload Field Definition ............................................... 385
Table 61 - NSM Switch Command Field Encoding ........................................................................ 386
Table 62 - Load Network Configuration Acknowledge Payload Field Encoding ....................... 387
Table 63 - Load Network Configuration Payload Field Encoding................................................ 389
Table 64 - Reply Network Status Payload Field Encoding ........................................................... 389
Table 65 - Load Power Switches Configuration Payload Field Encoding .................................. 391
Table 66 - PCM Switch Command Field Encoding ........................................................................ 392
Table 67 - Power Switch Configuration Acknowledge Payload Field Encoding........................ 393
Table 68 - Reply Power Switches Status Payload Field Encoding .............................................. 394
Table 69 - IDL Basic Integer Types ................................................................................................. 407
Table 70 - Interfaces Compliancy Matrix ........................................................................................ 450
Table 71 - Service Compliancy Matrix ............................................................................................ 450
Table A.1 - ASAAC Graphics Language ......................................................................................... 461
Table A.2 - Keys Referred to in Table A.1 ...................................................................................... 465
Table A.3 – Auxiliary Functions ...................................................................................................... 465
Table A.4 – Video Library Functions .............................................................................................. 466
Table A.5 – Texture Formats ........................................................................................................... 467

NATO UNCLASSIFIED 6
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

5 Introduction

5.4 Purpose

This document is produced under contract ASAAC Phase II Contract n°97/86.028.

The purpose of the ASAAC Programme is to define and validate a set of open architecture standards,
concepts & guidelines for Advanced Avionics Architectures (A3) in order to meet the three main
ASAAC drivers. The standards, concepts and guidelines produced by the Programme are to be
applicable to both new aircraft and update programmes from 2005.

The three main goals for the ASAAC Programme are:

1. Reduced life cycle costs,

2. Improved mission performance,

3. Improved operational performance.

The ASAAC standards are organised as a set of documents including:

- A set of agreed standards that describe, using a top down approach, the Architecture overview to
all interfaces required to implement the core within avionics system,

- The guidelines for system implementation through application of the standards.

The document hierarchy is given hereafter: (in this figure the document is highlighted)

Standard for Architecture

Standard for Software Guidelines for System Issues

• System Management
• Fault Management
• Initialisation / Shutdown
• Configuration / Reconfiguration
• Time Management
Standard for Packaging • Security
• Safety

Standard for Communications and

Network

Standard for Common Functional Modules

Figure 1 - ASAAC Standard Documentation Hierarchy

NATO UNCLASSIFIED 7
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

5.5 Document Structure

The document contains the following sections:

- Section 6, Scope,

- Section 7 Normative References,

- Section 8, Terms, Definitions and Abbreviations,

- Section 9, System Functions,

- Section 10, Software Architecture Definition,

- Section 11, Direct Interfaces,

- Section 12, Logical Interfaces Definitions,

- Section 13, Data Type Definitions,

- Section 14, Tailoring,

- Annex A, AGL.

NATO UNCLASSIFIED 8
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

6 Scope
The purpose of this standard is to establish uniform requirements for design and development of
software architecture for modular avionics systems as defined per ASAAC.

6.4 Software Architecture Overview

The ASAAC Software Architecture is based on a three-layer stack as shown by a simplified Figure 2.

Application Layer

APOS

Operating System Layer

MOS

Module Support Layer

Figure 2 - ASAAC Three Layer Software Architecture

Each layer is described in terms of it dependency/independency on both the aircraft system and the
underlying hardware.

Table 1 - Software Layer Independence

Software Layer Aircraft Dependency Hardware Dependency

Application Layer (AL) Dependent Independent

Operating System Layer (OSL) Independent Independent

Module Support Layer (MSL) Independent Dependent

6.5 Software Architectural Components

Figure 3 provides an overview of the software architectural components and software interfaces.

NATO UNCLASSIFIED 9
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Funct. Funct.
AM AM Apps
Apps SMLI SMLI
APOS APOS
S S
Operating GSM M RT-Blueprint RT-Blueprint M GSM Operating
System B B S System
S P P
M M
O O
GLI S
S

OLI
MOS MOS
MSL MLI MSL

Figure 3 - The Software Architecture Model

6.5.1 Functional Applications

The term "Functional Applications" relates to all functions that handle the processing of operational
data, e.g.

- Radar Applications,

- Mission Management,

- Stores Management,

- Vehicle Management System,

- Communication, Navigation and Identification.

6.5.2 Application Management (AM)

AM is responsible for the non-standardised system management, i.e. the AM performs the non-
generic system management. As an example, the AM may perform the mission/moding management.
The interface between the AM and GSM is the System Management Logical Interface (SMLI) (see
section 9.4.2).

6.5.3 Operating System (OS)

A Real-Time OS provides the particular part of OSL functionality that controls the real-time behaviour
of the Processing Element and its associated resources (see section 10.5.2).

6.5.4 Generic System Management (GSM)

The GSM is responsible for the management of the core processing (see section 9.4.1 and section
10.5.1). This functionality is divided into four areas:

- Health Monitoring,

- Fault Management,

NATO UNCLASSIFIED 10
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Configuration Management,

- Security Management.

6.5.5 Run-Time Blueprints (RTBP)

The RTBP contain the information (e.g. process description, routing information, fault management
data) required to configure and manage the core processing on which it is hosted (see section 10.6).

6.5.6 Module Support Layer (MSL)

The MSL encapsulates the details of the underlying hardware and provides generic, technology
independent access to low-level resources (see section 10.4).

6.5.7 Application to OS Interface (APOS)

The APOS is a direct interface that separates the aircraft dependent software (AL) from the aircraft
independent software (OSL). Its purpose is to provide the processes in the AL with a standardised OS
independent interface to those services provided by the OS, thus promoting the portability and re-use
of application software (see section 11.4).

6.5.8 Module Support to OS Interface (MOS)

The MOS is a direct interface that separates the OSL from the hardware dependent software (MSL).
Its purpose is to provide the OS with a hardware independent/technology transparent interface to the
functionality contained within the MSL. The MOS therefore allows the same OSL software to reside
on different implementations of a particular CFM regardless of the underlying hardware (see section
11.5).

6.5.9 System Management to Blueprints Interface (SMBP)

This direct interface, encapsulated within the OSL between the GSM and the blueprints, allows the
structure and implementation of the blueprints to remain non-standardised, while defining a
standardised interface to them (see section 11.6).

6.5.10 System Management to OS Interface (SMOS)

This direct interface, encapsulated within the OSL, describes the services provided by the OS to the
GSM (see section 11.7).

6.5.11 OS Logical Interface (OLI)

The OLI describes the intercommunications between two instantiations of OS's with regard to Virtual
Channel (VC) communications and data presentation (see section 12.4).

6.5.12 GSM Logical Interface (GLI)

The GLI describes the intercommunications between two instantiations of GSM (see section 12.5).
The nature of this inter GSM communication is hierarchical.

NATO UNCLASSIFIED 11
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

6.5.13 System Management Logical Interface (SMLI)

The SMLI standardises a VC based communication protocol between the AM and GSM. AM and the
GSM have to cooperate and to do so, they communicate and synchronise themselves via the SMLI
(see section 12.6).

6.5.14 Module Logical Interface (MLI)

This logical interface (communication protocol) defines the logical interactions between modules to
meet the module interoperability and system buildability requirements (see section 12.7).

NATO UNCLASSIFIED 12
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

7 Normative References
This European Standard incorporates, by dated or undated reference, provisions from other
publications. These normative references are cited at the appropriate places in the text and the
publications are listed hereafter. For dated references, subsequent amendments to or revisions of any
of these publications apply to this European Standard only when incorporated in it by amendment or
revision. For updated references the latest edition of the publication referred to applies (including
amendments).

[1] ASAAC2-STA-32420-001-HWG Final Draft of proposed Standards for Communications /

Issue 01 Network

[2] ASAAC2-STA-32430-001-HWG Final Draft of proposed Standards for Common Functional

Issue 01 Module

[3] ASAAC2-STA-32440-001-HWG Final Draft of proposed Standards for Packaging

Issue 01

[4] ASAAC2-GUI-32450-001-CPG Final Draft of proposed Guidelines for System Issues

Issue 01

[5] ASAAC2-STA-32460-001-CPG Final Draft of Proposed Standards for Architecture

Issue 01

[6] Common Object Request Broker Architecture: Core Specification

Version 3.0 - Editorial update formal/02-12-06, OMG

[7] ISO/IEC 14977 1996(E) EBNF specification

[8] ISBN 0-201-63276-4 Open GL Reference Manual

NATO UNCLASSIFIED 13
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

8 Terms, Definitions and Abbreviations

For the purposes of this standard, the following terms, definitions and abbreviations apply:

8.4 Terms and Definitions

Use of “shall”, “should” and “may” within the standards observe the following rules:

- The word 'SHALL' in the text expresses a mandatory requirement of the standard.

- The word 'SHOULD' in the text expresses a recommendation or advice on implementing such a
requirement of the standard. It is expected that such recommendations or advice be followed
unless good reasons are stated for not doing so.

- The word 'MAY' in the text expresses a permissible practice or action. It does not express a
requirement of the standard.

8.5 Abbreviations

AC Aircraft

AGL ASAAC Graphics Tag Language

AGT Absolute Global Time

AL Application Layer

ALT Absolute Local Time

AM Application manager

APOS Application to OS [interface]

ASAAC Allied Standard Avionics Architecture Council

ATM Asynchronous Transfer Mode

BIT Built-In Test

BMC Between Module Communication

CBIT Continuous BIT

CDR Common Data Representation

CFM Common Functional Module

CM Configuration Management

COTS Commercial-Off-The-Shelf

CPU Central Processing Unit

DMC Distributed Multicast Communication

NATO UNCLASSIFIED 14
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DPM Data Processing Module

EBNF Extended Backus-Naur Form

EW Electronic Warfare

FC Fibre Channel

FIFO First In First Out

FM Fault Management

GLI Generic System Management Logical Interface

GSM Generic System Management

HM Health Monitoring

HW Hardware

IA Integration Area

IBIT Initiated BIT

ID Identification

IDL Interface Definition Language

IF Interface

IMA Integrated Modular Avionics

IMC Intra Module Communication

IPC Intra Processor Communication

IPEC Intra PE Communication

LC Logical Configuration

LSB Least Significant Byte

MC Master Clock

MLI Module Logical Interface

MMM Mass Memory Module

MOS MSL to OS [interface]

MRC Master Reference Clock

MSB Most Significant Byte

MSL Module Support Layer

MSU Module Support Unit

NATO UNCLASSIFIED 15
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

N/A Not Applicable

NC Network Channel

NII Network Independent Interface

NIU Network Interface Unit

NSM Network Support Module

NW Network

OLI Operating System Logical Interface

OMG Object Management Group

OS Operating System

OSL Operating System Layer

PBIT Power-Up BIT

PCM Power Conversion Module

PE Processing Element

PSE Power Supply Element

PU Processing Unit

QoS Quality of Service

RE Resource Element

RC Remote Clock

RF Radio Frequency

RLT Relative Local Time

RTBP Runtime Blueprints

RU Routing Unit

SCU Switch Control Unit

SM Security Management

SMBP System Management to Blueprints Interface

SMLI System Management Logical Interface

SMOS System Management to OS Interface

SPM Signal Processing Module

SW Software

NATO UNCLASSIFIED 16
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

TC Transfer Connection

TLS Three Layer Stack

VC Virtual Channel

VL Video Library

NATO UNCLASSIFIED 17
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9 System Functions
This section describes the system context and the mapping of system functions onto software
architectural components.

9.4 System Management Function

Note: For requirements on the System Management including detailed examples refer to the
respective volumes of the “Final Draft of proposed Guidelines for System Issues” (see reference [4]).

The System Management is responsible for managing the ASAAC system during initialisation, all
operational phases in flight and on ground, and system shutdown until power-off. Thus, its tasks
include:

- Control of the system initialisation, reconfiguration, and shutdown processes,

- 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 OSL's of the
ASAAC Three-Layer-Stack model (Figure 3):

- The Application Management function (AM): Aircraft dependent, HW independent,

- The GSM function (GSM): Aircraft independent, HW independent.

The underlying principles of this architecture are the separation between hardware and aircraft
dependent layers and the separation between avionics 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.

NATO UNCLASSIFIED 18
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 4 - 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 applications 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 RE’s.

- IA’s 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 one or more PE’s.

- 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.

RE Level:

- The resource element is the lowest addressable level in the system management hierarchy
responsible for managing the functionality of a single Processing Element (PE).

9.4.1 GSM Function

The GSM function GSM is responsible for the management and control of all resources and
management of the ASAAC system behaviour via the use of RTBP (see 10.6).

NATO UNCLASSIFIED 19
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AC

IA1

IA2 IA3 IA4

RE1 RE2 RE3 RE4 RE5 RE6

Figure 5 - GSM Decomposition for RE-Management (Example)

Functions:

The GSM 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 including 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 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 RE’s

NATO UNCLASSIFIED 20
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AC

IA1

IA2
IA2 IA3 IA4
App1 App3
App4 App4
App2 App4

Figure 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 redundant application App4.

RACK 1
PCM NSM
1 AC
MMM DPM
1 1
RACK 2
PCM SPM
2 IA1
MMM DPM
2 2 MODULE
S
GPM
IA2 IA3 IA4
DPM
3

Figure 7 - GSM 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 application App4.

Configuration Data:

The configuration data is obtained from the RTBP via SMBP. The reconfiguration is defined through
dedicated sequences obtained via SMBP.

NATO UNCLASSIFIED 21
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Initialisation and Shut-Down:

Initialisation and shut-down is performed on three different levels:

- Application,

- System,

- Module.

9.4.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:

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 IA’s is depicted in Figure 8:

AC
AM GSM
Applications
Pilot Interaction

IA1
(RF-IA) GSM
AM
Applications
DASS Mgmt

AM GSM AM GSM AM GSM

Applications Applications Applications

Air to Air Mode Threat Warning Flight Plan
Air to Surface Jamming Map Display
IA2 Mode
IA3 IA4
(Radar – IA) (EW – IA) (Nav – IA)

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 protocol for the change of the logical configuration.

NATO UNCLASSIFIED 22
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

External Interfaces:

There are no standardised external interfaces of the AM. All external interfaces are application-
dependent.

9.4.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 11.4). 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 has been created). In either case the fault is handled through a standardised
process (refer to Final Draft of proposed Guidelines for System Issues document - [4]) 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 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 thread.

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 situations 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.

9.4.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 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 paired 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,

- Get IBIT Result: Retrieves the stored IBIT result.

NATO UNCLASSIFIED 23
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

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

9.4.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 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.

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 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 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 about 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 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.

9.4.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 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 available. 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

NATO UNCLASSIFIED 24
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

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 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.

9.5 Communication

9.5.1 ASAAC Communication Model

9.5.1.1 Principle

The ASAAC Communication stack (see Figure 9) shall be supported by:

- VC’s (provided by OSL),

- Transfer Connections (TC) (provided by MSL, hardware independent),

- Network Channels (NC) (provided by MSL, hardware dependent).

Virtual Channel Virtual Channel

Direct Interface

Transfer Connection Transfer Connection

Network Channel Network Channel

Peer to Peer Communication

Figure 9 - The 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)).

NATO UNCLASSIFIED 25
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.1.2 VC

Inter-process communication is based on VC’s. VC’s 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 data onto a particular VC. Similarly, a receiving process has no
knowledge of the sending process; it merely receives certain data from certain VC’s.

The source and destination processes, the data items to be transmitted between them, and the VC’s,
over which they are transmitted, are defined during system design. During run-time this information is
provided by the RTBP. Consequently, for a given system configuration, the set of VC’s 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 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 knowledge about how many users shall be supposed to receive the message.

9.5.1.3 TC

The basic communication link offered by the NII is the Transfer Connection (TC). Data transfer via
TC’s 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 VC’s

- A TC supports streaming communication mode.

9.5.1.4 NC

The ASAAC Standard does not establish any requirement against the NC's. The NC's shall be
managed within the MSL.

Blueprint data shall configure the properties of a NC. These are implementation dependent data and
therefore shall be transparent to the OSL software.

NATO UNCLASSIFIED 26
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.2 Types of Data Transfer

VC VC IPC

IPEC
TC TC IMC

BMC
NC NC

Figure 10 - Types of Data Transfer

Figure 10 shows the 4 types of communication, based on their transfer scope:

- Intra Processor Communication (IPC)

is the communication within a processor and is handled at OSL level by VC.

- Intra Processing Element Communication (IPEC)

is the communication between processors within a PE and is handled at MSL level by TC.

- Intra Module Communication (IMC)

is the communication between PE’s within a Module and is handled at MSL level by TC.

- Between Module Communication (BMC)

is the communication between CFM’s and is handled at OSL level by a VC and at MSL level by a
TC and a NC.

9.5.3 Communication Configuration

The ASAAC Communication shall be configurable based on blueprint data (see section 10.6).

The scope of a local VC Id is limited to a single Application Process. Its value is determined by the
implementation of the Application Process it is associated with. This value is unique within that
Application Process. It is independent of the design of the other Application Processes.

GSM uses blueprint data on both sending and receiving sides, and shall initiate the OS to create
communication objects based on blueprint information in order to configure the communication:

- The OS creates an instance of a VC. A global VC Id, which is unique within the System, identifies
a VC. It shall be identical on both sending and receiving sides.

- The OS attaches an Application Process local VC to a system global VC.

NATO UNCLASSIFIED 27
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- The OS creates an instance of a TC. A global TC Id, which is unique within the System, identifies
a TC. It shall be identical on both sending and receiving sides.

- The OS maps a VC onto an appropriate TC.

Sending Part
Receiving Part
Process A
Local Vc Id 1 Local Vc Id 2 Process B AL

VC OSL
Global Vc Id VC

TC Global Tc Id TC
MSL

Network

Figure 11 - Communication Concept

The definition of NC’s shall be part of the TC parameter set, as NC’s are associated to the definition
of a TC. Therefore, NC’s are not handled as a separate entity.

9.5.4 Communication Protocols

9.5.4.1 Introduction

The ASAAC Communication stack defines the protocols for establishing a communication between
ASAAC layers.

NATO UNCLASSIFIED 28
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.4.2 VC to VC

CFM 1 CFM 2
PE PE
AL Process B
Process A

Reaching
Application
VC Process
Setting VC
OSL VC end-point
Header

TC TC
Setting TC
Header
MSL
Reaching PE
end-point

Setting Reaching
Network Network
end-point
Header
NIU NIU

Network

Figure 12 - Between AL Communication Routing

A communication between processes onto two different CFM’s can use the following mechanisms:

- Process-to-Process: The VC allows a Process within a PE to be reached.

- PE-to-PE: The TC allows a PE within a CFM to be reached.

- CFM-to-CFM: The NC allows a CFM onto the Network to be reached.

The VC-to-VC supports communication between:

- Application processes,

- GSM’s, the inter-GSM communication is a standardised logical interface, namely GLI, see section
12.5,

- Application Manager and GSM, which is a standardised logical interface, namely SMLI, see
section 12.6.

9.5.4.3 TC to TC

The access and control of TC’s shall be at either the boundary between the OSL and MSL, namely
the NII, or within the MSL.

As described above, TC-to-TC communication supports BMC, IMC and IPEC communication. The TC
header is necessary for the IPEC and IMC. The TC and Network headers are both necessary for
BMC.

It shall be noticed that the inter-MSL communication is a standardised logical interface, namely MLI,
see section 12.7.

NATO UNCLASSIFIED 29
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.4.4 Raw VC Transfer

Raw VC transfer is needed when an Application Process communicates with an MSL on another PE
or with non-core devices, an example of this is the Graphics Management, see section 9.9.

An application sending a raw VC:

- The sending Process uses a VC, which is mapped onto a TC,

- The APOS VC message is provided as it is, without attaching a VC header,

- A CFM or a non-core device will receive the TC. It will be decoded as required.

When a raw VC is received:

- The CFM or non-core device as required encodes the TC payload,

- A raw VC is identified by means of its properties as defined by the blueprint VC information,

- When recognised by the OS as a raw VC, it shall be processed without removing the VC header,

- The usage of a raw VC implies that every TC carrying a raw VC is restricted to a single VC.

9.5.4.5 Routing Headers

In order to route a message between start-point and end-point, information is needed:

- A header that contains information on its features,

- An identifier that describes each message layer. This identifier allows the identification of the
routing information in internal tables.

Each header shall provide information to reach an end-point (see Figure 13):

- The Network Header provides information to reach the targeted CFM,

- As several TC’s may use the NC, the TC Header shall identify the TC. This identification allows
the targeted PE to be reached,

- As several VC’s may use the TC, the VC Header shall identify the VC. This identification allows
the targeted Process to be reached.

NATO UNCLASSIFIED 30
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The MSL/NIU start-point sets this header.

Network Header The MSL/NIU end-point strips it and provides
the rest to the MSL/PE
The MSL/PE start-point sets this header. The
TC Header MSL/PE end-point strips it and provides the
rest to the OS
The OS start-point sets this header. The OS
VC Header end-point strips it and provides the rest to the
Process

Message The Process start-point sets this message.

Payload The Process end-point receives it.

Figure 13 - ASAAC Message in BMC Data Transfer

The layer within the ASAAC Communication stack on which the transfer is happening determines the
set of routing data required. E.g. for IPC only a VC header is sufficient, if only VC communication
functions are involved.

The TC Header and the VC Header are standardised. Table 3 defines their applicability to the data
transfer modes. The Network header is not standardised, as it is technology dependent.

Table 3 - Routing Information and Data Transfer

Data Network TC VC
Transfer

BMC Yes Yes Yes

IMC No Yes Yes

IPEC No Yes Yes

IPC No No Yes

9.5.5 Multicast
The ASAAC Communication shall support the Multicast communication. This capability allows a
sender to be connected to many receivers.

The multicast capability shall be supported at VC and TC level of the ASAAC Communication stack.

As there are multiple receivers, this possibly leads to a combination of several types of data transfer
(IPC, IPEC, IMC and BMC) at the same time.

The VC Multicast has a unique identifier. The sender process has no knowledge of its Multicast
behaviour. In IPC that VC shall be attached to all receiver processes.

In case of the VC using TC (IPEC, IMC and BMC), there are two possibilities:

NATO UNCLASSIFIED 31
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Using a single TC providing Multicast capability,

- Using multiple simple TC’s.

9.5.5.1 Single Multicast TC

CFM 2
PE 1
Receiver 2
CFM 1
TC VC
PE 1
Receiver 3
Emitter VC TC Network
PE 2

TC VC Receiver 4

Receiver 1

TC VC Receiver 5

Receiver 6 VC TC PE

PE 2 CFM 3

Figure 14- Multicast Scheme With a Single TC

In this example the TC Identifier is unique. According to the figure above, the types of data transfer
are (from the emitter to):

- Receiver 1: IPC, the VC is attached as outgoing to the emitter, and as incoming to the receiver,

- Receiver 2 and Receiver 3: BMC, the incoming TC is attached to a VC that incoming VC is

attached to both receivers,

- Receiver 4: BMC, it shall be noticed that the TC on CFM2/PE1 and CFM2/PE2 has the same
identifier. It means that the MSL shall be able to handle multiple end-points with the same
identifier,

- Receiver 5: BMC,

- Receiver 6: IMC, the outgoing TC from PE1 goes to both the network and PE2. It is a case of a
handling of a TC with multiple end-points, as well.

Actually, there are two methods for crossing the Network.

1. The MSL at NIU level duplicates the TC message in several messages with the Network Header
corresponding to the end-point onto the Network.

2. The MSL at NIU sends a unique TC message and a Network header indicating the Multicast
behaviour. Then the Network resource handles the Multicast and provides the message to the
end-points.

NATO UNCLASSIFIED 32
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.5.2 Multiple Simple TC’s

CFM 2
PE 1
Receiver 2
CFM 1
TC1 VC
PE 1
TC1 Receiver 3
Emitter VC Network
TC2 PE 2

TC3 TC2 VC Receiver 4

Receiver 1
TC4

TC3 VC Receiver 5

Receiver 6 VC TC4 PE

PE 2 CFM 3

Figure 15 - Multicast Scheme With Multiple Simple TC’s

At the sending side the Multicast VC is attached to several TC’s. At OS level the VC Message is sent
out onto several TC’s.

9.5.6 Distributed Multicast

9.5.6.1 Introduction

The Distributed Multicast Communication is only applicable to Signal Processing. The Distributed
Multicast Communication is an N:M communication (N senders to M receivers) using both
multicasting and fragmentation.

Distributed Multicast is involved when it is necessary to use data parallelism for decreasing the time
processing of a sequence of Signal Processing operations. The input data are separated in subparts
that are processed in the same time by the several processors. Different processors process data, but
the executed algorithm is identical.

Processor 1 SP
Subpart 1 algorithm

Subpart 2 Processor 2

Input data Subpart 3 Processor 3

Subpart 4 Processor 4

Subpart 5 Processor 5

NATO UNCLASSIFIED 33
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 16 - Data Parallelism

The distributed multicast allows the re-distribution of data spread over several processors. One typical
case for using distributed multicast is the corner turn. This function inverses the rows and columns of
a table, as it is shown below.

m1
1 ...
c1 a1 a
a2
b1 a1 b1c1 m1 a3
m2...
2 c2b2 a1 a2 b2c2 m2
b3 b2 b1
a2 a3 b3c3 m3 b
a3
m3...c3 b3 c3 c2
c1
3 an
bn c
cn anbncn mn
... m2
mn m1
n
m

Figure 17 - Corner Turn

In the figure above, [1..n] are senders and [a..m] are receivers. Actually, the matrix to be inverted is
virtually constructed by the communication mechanism.

Each sender shall apply a distribution law for addressing data to each receiver. A distribution law is a
linear law that defines how to fragment an emitted buffer in order to generate the different buffers to
be sent to each receiver.

Each receiver shall apply a collection law for addressing data from each sender. A collection is a
linear law that defines how to build a buffer with the received fragmented buffers from several
senders.

The N:M communication or distributed Multicast Communication may be considered from:

- The sending part as a 1:M multicast communication, where the M receivers get a different
fragment,

- The receiving part as a N:1 communication, where N senders give a fragment.

The corner turn may be used in a context that needs several dimensions. Data in a radar application
is organised in multi dimensional arrays. In the following radar example, a value is attached to a
particular antenna beam, a particular pulse, and a particular range gate. This leads using a corner in
three dimensions (pulse, range gate, beam).

NATO UNCLASSIFIED 34
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Pulses Pulses

Range Range
gates gates

Beams Beams

Figure 18 - Corner Turn in Three Dimensions

The slices represent a part of the cube that is processed by one processor. The slices may be
overlapped.

9.5.6.2 Requirements

The distributed multicast shall provide the following features:

- A Processor involved in distributed multicast may be a sender and a receiver for this transaction,

- Each sender and receiver may be located in one or several Processing Elements, which may be
located in one or several SPM,

- For each sending Processor, one distribution law per receiving Processor shall be defined,

- For each receiving Processor, one collection law per sending Processor shall be defined,

- The signal processing application shall be able to process a fragmentation in one, two or three
dimensions,

- Each message sent on a TC dedicated to the Distributed Multicast Communication shall be

preceded by the TC identifier for routing to the receiver, and fragment identifier for reconstitution,

9.5.6.3 Distributed Multicast Communication in TLS

The present section introduces how data are sent then received viewed from one processor.

The Application shall use a VC for sending data. This VC shall be specified as a Raw VC. This VC is
attached to a TC specified as a DMC TC.

The OS shall execute the MOS service dedicated to DMC purpose: sendFragmentedTransfer.

The distribution of the DMC TC is performed within the MSL. The individual fragments shall be
assigned to separate TC’s. Each receiver shall be assigned a TC. The TC identifier identifies the
receiver.

The receiving MSL shall collect TC’s with TC Identifier specified as DMC TC, and reconstitute the
message based on Fragment Identifier, which identifies the sender. When the buffer reconstitution is

NATO UNCLASSIFIED 35
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

completed, it is retrieved by the MOS service receiveFragmentedTransfer. The MOS service may use
the same TC Id as the sending point.

The OS shall execute the MOS service receiveFragmentedTransfer for passing data to the
Application through a Raw VC.

Figure 19 introduces a corner turn example for DMC processing on one Processor.

Application
a11 a12 a13 a14 a15 a16 a17 a18 receiveMessage(VC1)
a11 a21 a31 a41 a51 a61
a41 a42 a43 a44 a45 a46 a47 a48
a15 a25 a35 a45 a55 a65
sendMessage(VC1) receiveFragmentedTransfer(TC100)
OS
a11 a21 a31 a41 a51 a61
a11 a12 a13 a14 a15 a16 a17 a18 a15 a25 a35 a45 a55 a65

a41 a42 a43 a44 a45 a46 a47 a48

Collection
SendFragmentedTransfer(TC100) law
MSL
a11 a12 a13 a14 a15 a16 a17 a18 a11 a15 a21 a25 a31 a35
Distribution TC1
a41 a42 a43 a44 a45 a46 a47 a48 law DSP1 a41 a45 a51 a55 a61 a65
TC4 TC2
TC1 TC1
TC3 DSP2
DSP4 DSP2 DSP3
DSP3

Figure 19 - Illustration of the Involved Services in DSP1

9.5.6.4 Message Fragmentation

The message fragmentation processes data selection follows a linear law that provides either a
distribution or collection law depending on whether it is applied respectively on the sending or the
receiving side.

In the corner turn example data addresses shall be computed according the following C-like formula:

for( a3 = 0; a3<N3; a3++ ) {

for( a2 = 0; a2<N2; a2++ ) {
for( a1= 0; a1<N1; a1++ ) {
DataAddress = Address0 + a1*Inc1 + a2*Inc2 + a3*Inc3 ;
}
}
}
Where:

- Address0 = initial Address of the internal buffer where the fragmentation is started,

- Nx: Data length of the X dimension,

- ax: Current Index of the X dimension,

- Incx: Increment number of the X dimension,

NATO UNCLASSIFIED 36
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- x: Dimension number 1 (first dimension) 2 (second dimension) 3 (third dimension).

If the fragmentation is processed in the context of two dimensions: N 3 and Inc3 are equal to zero.

9.5.7 Streaming
Streaming data are continuous data. Two basic applications are video or audio purposes. Streaming
data shall only be handled at the TC Level. This stream of data may contain identified blocks of sub-
data, e.g. video data may contain individual frames.

To allow the system to keep up with this stream, data shall be transferred from the Network Interface
Unit (NIU) to the Processing Unit (PU) with the same rate as data arrived at the Network Interface
unit. In case this requirement is not fulfilled, the stream is interrupted, which has to be handled as an
error

For a streaming TC, the NIU will be provided with information to allow the direct transfer of data to the
PU. The implementation of the MSL, which encompasses the NIU and the PU, is project dependent.
Therefore, the configuration data specifying the Streaming behaviour shall be implementation
dependent.

9.5.8 Data Representation

Several ASAAC components of a CFM are able to send data to components of remote CFM’s. These
components are in MSL, or OSL, or AL levels and may involve data representation mechanisms.

The different types of message, which may be submitted to a data representation, are:

- MSL Level:

- TC supporting VC Messages,

- TC supporting MLI Messages.

- OSL Level:

- VC supporting Application, GLI and SMLI Messages,

- VC supporting OLI Messages.

- APOS client level:

- Application Messages as typed Messages,

- Application Messages as raw Messages.

The data representation impacts each ASAAC layer.

9.5.8.1 MSL Level

The data representation is not configurable at MSL level. It means that all parts of a message that is
under the responsibility of the MSL, are hard-coded.

- TC supporting VC Messages: The TC header structure is fixed and is known, the payload
message is not modified and is given to the OS.

NATO UNCLASSIFIED 37
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- TC supporting MLI Messages: The structure of all MLI Messages, header and payload message,
is known. The payload message may be processed and given to the OS in the expected format.
(I.e. If the CFM status is requested, it shall be replied in a format, which shall be understandable
by the hosting processor). For more details, refer to MLI section 12.7.

9.5.8.2 OSL Level

9.5.8.2.1 Principle

The data representation may be applied to VC Header if requested.

The data representation shall not be applied to raw messages.

The data representation shall be applied to typed message if requested.

The data representation shall not be applied to VC between processes on the same PE.

The data representation shall be based on a subset of the OMG CDR. Big-endian orientation is
selected.

Resource Element A Resource Element B

Local to RE A Local to RE B

APOS

OSL Local to CDR OSL CDR to Local

Translation Translation
Based on IDL Based on IDL

MOS

MSL
MSL MSL
MSL

All messages transmitted in CDR format Network

Figure 20 - Data Representation

For typed messages, the OS on information contained in blueprints does a local translation of a
message. They translate the message:

- At the sending side, into the OMG CDR format. See referenced document [6] section 15.3,

- At the receiving side, into the format understandable by the hosting processor.

Figure 20 shows the continuation of translation actions made on a message sent from resource
element A and received by resource element B.

NATO UNCLASSIFIED 38
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.5.8.2.2 Data Representation Configuration

Blueprints contain data representation information:

- A flag in the SMBP VcToTcMappingDescription structure indicates whether the data

representation mechanism is required. When this flag is set, all VC’s on that TC shall be
processed, otherwise no processing shall be applied. In Multicast communication all receivers
shall have the same features.

- The SMBP VcDescription structure:

- A flag indicating whether the message is typed or raw,

- If the message is specified as typed, a provider-dependent representation of the message

data type in the VcDescription following the IDL message definition.

The GSM shall configure the data representation processing of the OS with the blueprint information.

9.5.8.2.3 OLI Messages

The OLI Messages are typed messages. Their description is specified in IDL format. As they are
standardised, they are not described in the blueprints.

For more detail, refer to section 12.4.

9.5.8.3 APOS Clients

The possible APOS clients are the processes in the AL or in the GSM. APOS clients do not manage
data representation and shall not be aware of such translation actions. APOS clients send typed
messages or raw messages through VC’s.

9.5.8.3.1 Raw Message

For raw message (stream of bytes), application data shall send and receive without interpretation. In
this case, data representation mechanisms shall not be applied.

9.5.8.3.2 Typed Message

In order to apply data representation on typed message APOS clients shall be built according to some
constraints:

- Message data type definitions are based on a subset of IDL types,

- Programming languages and compiler options used for building APOS clients processes and OS
components shall be compliant to generate the standardised memory alignment

9.5.8.3.2.1 Definition of Typed Messages

Message data type definitions shall be based on a subset of IDL and shall contain:

- Simple types,

- Constructed types.

NATO UNCLASSIFIED 39
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The table below specifies the subset of IDL primitive types used by simple types or by constructed
types.

Table 4 - IDL Primitive Types

IDL Type Octet alignment CDR Representation

octet 1 Uninterpreted 8-bit

short 2 octet Big-endian

unsigned short
0 MSB

1 LSB

long 4 octet big-endian

unsigned long
0 MSB

3 LSB

long long 8 octet big-endian

unsigned long long
0 MSB

7 LSB

float 4 IEEE 754-1984

octet big-endian

0 s e1

1 e2 f1

2 f2

3 f3

double 8 IEEE 754-1984

NATO UNCLASSIFIED 40
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

IDL Type Octet alignment CDR Representation

octet big-endian

0 s e1

1 e2 f1

2 f2

3 f3

4 f4

5 f5

6 f6

7 f7

long double 16 IEEE 754-1984

octet big-endian

0 s e1

1 e2

2 f1

3 f2

4 f3

5 f4

6 f5

7 f6

8 f7

9 f8

10 f9

11 f10

12 f11

13 f12

14 f13

15 f14

NATO UNCLASSIFIED 41
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The table below specifies the constructed types. The APOS client shall use types as described in the
IDL constructed type column. The OS ensures the data representation and shall encode as it is
described in the CDR Encoding column.

Table 5 - IDL Constructive Types

IDL Constructed CDR Encoding

type

struct Components encoded in order of the definition. A structure may be composed of

primitive types and constructed types.

array Encoded array elements in sequence. The encoded element may be either a primitive
type or a constructed type. An array shall be associated to a unique type of element.

sequence Number of elements followed by the encoded sequence elements in sequence. The
number of elements shall be a simple unsigned integer type. The encoded element may
be either a primitive type or a constructed type. A sequence shall be associated to a
unique type of element.

string Length of the string followed by the sequence of characters encoded in single-byte form,
including a null character. The length of the string shall be a simple unsigned integer
type. An empty string has a length of one. The length of the string shall be a simple
integer type. The encoded elements shall be an octet.

union Discriminant tag followed by the representation of the selected member. The
discriminant tag shall be a simple unsigned integer type. The selected member may be
either a primitive type or a constructed type.

It is possible to merge several IDL constructed types with either a fixed size or a variable size as long
as they are encapsulated in a structure and the additional information that is added by the CDR
encoding is also an element of the structure. In the Data representation specification of the message,
this additional information shall be a key word depending of the type of the IDL constructed types.

- Sequence: Number of element shall be a part of the structure specified by a key word,

- String: Length of string shall be a part of the structure specified by a key word,

- Union: Discriminant tag shall be a part of the structure specified by a key word.

9.6 Security Management

Security Management is the GSM function that is responsible for the secure transfer of protectively
marked data throughout the system. The key responsibilities of Security Management are the:

- Management and distribution of keys for authentication and encryption as required,

- Provision of classification and clearance data to the reference monitoring function,

- Implementation of authentication and software encryption algorithms,

- Compilation of a Security Audit Log - Logging and collating.

NATO UNCLASSIFIED 42
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data
Loader
System
Management
GSM
ASM
AC
SM Level

GSM
IA
ASM SM Level

GSM
RE
SM
Level

Security VCs
GLI
Management

Figure 21 - GSM Interfaces

The Security Management Function is actually implemented in the form of a platform specific part, the
Application Security Management (as part of AM), and the hierarchy of Generic System Security
Management.

NATO UNCLASSIFIED 43
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data MMM
Application
Loader Security Mgr

OS AC DB
GSM-SM

LOG

VC GLI
Communications Communications

Application Application

OS OS
RE RE
GSM-SM GSM-SM

DB = Database

Figure 22 - Main Security Related Architectural Components

9.6.1 Application Security Management

The Application Security Management is the part of the Security Management Function that is
provided specifically for a particular platform and therefore it resides above the APOS alongside the
Application Manager.

Its purpose is twofold:

- To act as an interface between the data loader and the rest of the IMA System,

- To act as an interface between the database holding the protectively marked data and the
functional applications which are to process the protectively marked data.

Note: The data loader and its interface are located outside the ASAAC core.

9.6.2 Generic Security Management

The GSM-SM is that part of the Security Management Function that is applicable to all platforms.

Its purpose is twofold:

NATO UNCLASSIFIED 44
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- To enable the secure transmission of protectively marked data through the use of
encryption/decryption and authentication,

- To write detected attempted security breaches to the Security Log.

9.6.3 Encryption/Decryption and Authentication

The OS intercepts data being transferred or received and determines by the means of a look-up table
as to whether the data being transferred is protectively marked. If it is, the OS is responsible for
sending it to the GSM-SM, passing the data and the VC Id, so based on blueprint information the
appropriate action can be performed on it. E.g.: Encryption, Decryption, and Authentication.

Functional
Application
Does this data need ‘A’
to be Encrypted?
Yes it Does
Encryption takes
a place here

b
VC SM
Handler Functional
Application
c
‘B’
OS GSM
GSM Does this data need
OS
d to be Decrypted?
d
Yes it Does

c
SM VC
Handler

b
GSM OS
GSM OS
a

Decryption takes
place here

Figure 23 - VC transferring Data Requiring Encryption & Decryption

The set of protectively marked messages is dependent of system mode and defined by means of
blueprints. As part of the initialisation/configuration process, the GSM-SM resident on RE’s
processing protectively marked data undergo a set of predefined actions. The final action of the GSM-
SM in this mode changing process shall be to call the SMOS service getPMData.

This shall be a blocking call and will only be serviced when the OS requires a security related action
to be performed on some protectively marked data. This call will return the VC Id transferring the data
in question and the data being transferred. The GSM-SM will then use the VC Id as an entry into a
look-up table that has been generated during the configuration phase in order to determine what
action to perform on the data and what key to use.

The processed data will then be returned to the OS VC services using the SMOS service
returnPMData.

NATO UNCLASSIFIED 45
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.6.4 Security Audit

The purpose of the Security Audit is twofold

- Historic record of all security related functions to aid accreditation. (Selectable),

- Log of attempted security breaches.

The key purpose of the security Audit is for logging any attempted security breaches during aircraft
operation.

These shall be reported to the GSM-SM, by means of the SMOS service getAuditData.

- The OS shall be responsible for reporting any breaches of the security policy,

- The Reference Monitoring shall be responsible for capturing any breaches of the multi-level
security policy,

- The GSM-SM itself will be responsible for detecting the failing of authentication.

9.6.5 Security Reference Monitoring

The role of the Security Reference Monitoring is to enforce the implementation of the security policy
and to detect attempted breaches of the policy. The key responsibilities of the reference monitor are
the:

- Implementation of a run-time clearance/classification validation algorithm (e.g. Bell-LaPadula) -

i.e. Checking,

- What process thread is calling which service,

- The data being transferred between the process thread and the service.

9.7 Module Management

The Module Management may be split in two parts.

- From an internal point of view: where the CFM is booted, and then goes to a state where it is
ready to download the whole TLS,

- From an external point of view: where a super-ordinate CFM controls the initialisation of a
subordinate CFM.

The Module Logical Interface (MLI) supports these two aspects of Module Management. The MLI
shall allow access to a CFM after the CFM has been powered-up and initialised via a defined network
route. It shall provide the following functions:

- To provide the CFM PBIT (Power-up Built-in-Test),

- To retrieve the CFM current status,

- To retrieve the CFM characteristics,

- To download the ASAAC SW stack to a CFM,

- To configure a CFM (for NSM and PCM),

NATO UNCLASSIFIED 46
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- To synchronise the CFM’s time,

- To send and receive test messages to and from a CFM.

The MLI protocol shall be the same for all CFM types. The MLI allows initialisation, configuration and
synchronisation of the CFM’s in an ASAAC Core system.

The MLI services are specified in section 12.7.

9.8 Mass Memory Management

9.8.1 Overview
The MMM is providing a Mass Memory Storage capability. It provides the other CFM with the file
access and storage functions in an ASAAC System.

The MMM may contain several types of file, dependent on implementation, e.g.:

- Images incorporating the components of the TLS: MSL, OS, GSM and blueprints,

- Software Applications,

- Data configuration for the Network,

- Data configuration for the power switches,

- Data configuration for the CFM communication at power up time (Routing Table),

- Data for application,

- Security data (e.g. encryption keys).

The MMM provides servers to CFM that need to access to these files. The layer containing the server
depends upon the layer containing the requester.

The direct file access is performed only on the MMM. The other CFM’s use the OLI to perform remote
file access.

It shall be noticed that remote CFM rights to file access are not supported by the Mass Memory
Management. It is a part of the Security Management policy. It is based on a secure communication
and possible encryption.

9.8.2 MMM Local File Management

The set of services regarding the file access shall be specific to the MMM. There shall be no local File
Management on CFM except on MMM.

There shall be a set of File Handling services in the APOS specific to the MMM. There shall be a set
of data storage handling in the MOS specific to the MMM.

The APOS File Handling provides a set of services that allows multiple accesses. This means multiple
users shall be able to process a file (different processes or different threads within a process). The
different users shall be able to perform concurrent operations. Only the file access rights shall cause
access restrictions.

NATO UNCLASSIFIED 47
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.8.3 Application File Access

Application on a remote CFM shall access a file by communicating with an MMM. The requesting
Application Process on the remote CFM shall act as a client and an Application Process on the MMM
shall act as a server. The client/server communication link uses VC and it is based upon a request /
reply mechanism. One VC is required for the request and a second VC for the reply.

The communication is
based on VC with a specific
logical interface Application Logical
MMM CFM
Interface
Application
File Application
Server Process

GetCbitResul
t SPB

Data Cbit
error

Network

Figure 24 - File Handling by a Remote Application

The MMM performs the APOS File Handling service and sends the result to the requesting
Application.

This shall be a specific logical interface. Its definition depends on the implementation.

9.8.4 CFM Download

On start-up, an ASAAC system relies on a CFM to initially boot up in a standalone mode. All other
CFM’s subsequently initialised have a resident MSL, only. A CFM, which has a complete software
stack, will provide the GSM Control of Modules. This Function will take care of the booting of the other
CFM’s.

Software or configuration information can be loaded from a CFM/PE with a complete TLS to a remote
PE or MSU with only a MSL resident.

- Images incorporating the components of the TLS: OS, GSM and blueprints,

- Data configuration for the Network,

- Data configuration for the CFM communication at power up time.

The communication mechanism for this is the Module Logical Interface (MLI) based on TC’s.

9.8.4.1 CFM to be booted is an MMM.

The MMM is assigned with the responsibility for the GSM Module Control. The TC’s between the
MMM and a set of controlled CFM are defined within the blueprints and have been configured.

NATO UNCLASSIFIED 48
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The communication is
based on TC/MLI
MMM SubordinateCFM

AL
requestDownloadToCfm
CFM
OSL GSM Loader

MLI
GetCbitResult SPB

MSL CFM
Cbit error
Booter

Network

Figure 25 - MMM Download onto a CFM with only the MSL

Sequence of download operations is:

- The TC’s on the MMM are defined within the blueprint and have been configured,

- Reading the Blueprint the GSM initiates a download by a SMOS service passing all necessary
information to the OS,

- Then the OS builds messages and sends them in performing dedicated MOS service, which uses
TC on a protocol compliant to MLI Download Management.

At initialisation, the receiving CFM has one default TC ready to receive an MLI message.

First, the Network configuration is downloaded onto the NSM. The other CFM’s are then reachable.

Next, the configuration for the CFM communication is downloaded. The CFM is then able to respond
to the MLI request as the reply MLI TC’s corresponding to the request MLI TC are known and
configured.

Finally, after the PBIT result request, the images incorporating the TLS components can be
downloaded.

NATO UNCLASSIFIED 49
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.8.4.2 CFM to be booted is not an MMM

Only MSL is available

on the Targeted CFM

Requesting CFM MMM Targeted CFM

AL
requestDownloadToCfm
OLI OLI OLI
Client
OSL GSM Server

GetCbitResult SPB GetCbitResult SPB

MLI
MSL Cbit error MLI Interpretation
Cbit error

Network

The communication is based

on VC/OLI then TC/MLI

Figure 26 - CFM Download onto a CFM with only the MSL

In this case, this CFM is not able to download files by its own on a targeted CFM.

Sequence of download operations is:

- The VC’s between the MMM and requesting CFM are defined within the blueprints and have been
configured,

- The TC’s between the MMM and the targeted CFM are defined within the blueprints,

- Reading the blueprints the requesting CFM/GSM initiates a download by a SMOS service passing
all necessary information to the OS,

- The requesting CFM/OS builds and sends the OLI request message in using VC on a protocol
compliant to OLI Download Management,

- The MMM/OS receives the OLI request and accesses to the file to be downloaded,

- The MMM/OS performs the download process onto MLI,

- The MMM/OS sends an OLI reply on VC to requesting CFM/OS when the download process is
over. The VC Id of the OLI reply is computed from a rule that depends on the OS implementation.

The requesting CFM can initiate the three download previously cited in the first case.

9.8.5 Application Downloading

Before any Application Process can be downloaded the TLS needs to be up and running on a
CFM/PE. The GSM/CFM performs a SMOS service for Process creation. An OLI request on VC is
sent from the OS/CFM to the OS/MMM.

NATO UNCLASSIFIED 50
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The communication is
based on VC/OLI

MMM CFM

CreateProcess
Application OLI Application
Processes Processes
Server Downloader GSM

GetCbitResult SPB

Cbit error

Network

Figure 27 - Application Download

Sequence of operations is:

- The VC’s between the MMM and the CFM are defined within the blueprints and have been
configured,

- Reading the blueprints the CFM/GSM initiates a process creation,

- The CFM/OS sends an OLI request using VC on a protocol compliant to OLI file reading,

- The MMM/OS receives the OLI request and accesses the file to be sent,

- The MMM/OS sends an OLI reply on a VC to the CFM/OS with the required data. The VC Id of
the OLI reply is computed from a rule that depends on the OS implementation.

The File Application is retrieved by the CFM/OS, which creates the Application Process.

9.9 Graphics Management

The ASAAC Graphics concept provides a system graphics capability for driving cockpit and
maintenance panel displays. The concept maximises the potential for software portability and re-use
and employs the standard ASAAC architectural components (e.g. APOS, VC’s etc) wherever
possible.

The graphics capability is realised through the use of one or more graphics functional applications
(hosted on a data processor) in conjunction with one or more graphics engines (hosted on a Graphics
Processing Module).

NATO UNCLASSIFIED 51
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DPM GPM
Graphics Engine
DP with TLS DP with TLS DP

Graphics Graphics
App Graphics App
Graphics
Library
Library

APOS APOS

VC Mgmt Rendering
VC Mgmt
Software

MOS MOS

Comms Comms
AGL Graphic
Graphic
Interpreter
sAccelerat
Accelerator
s
or

AGL

Figure 28 - Graphics Concept

The graphics functional applications generate a stream of graphical commands (AGL), which are then
transferred over raw VC’s to the graphics engines. The graphics engines take the ASAAC Graphics
tags, interpret and render them and then convert the resulting data into a bit-map image (frame) prior
to transmitting it to one or more displays via the network as shown in Figure 28.

Roll, Pitch &

Heading

Graphics
Graphics
Application AGL
AGL
Application AGL Interpreter
Interpreter

Graphics
Graphics Rendering
Rendering
Library
Library Software
Software

Graphics
Graphics
Accelerator
Accelerator

ASAAC Graphics Standard

Figure 29 - Graphics Standard

The graphics application developer does not write applications using AGL but writes software using
the graphics language/standard of their choice and it is these commands that get translated into AGL
through the use of an appropriate graphics library and then interpreted by the Graphics Engine. See
Figure 29. It is the use of AGL that promotes software re-use and portability and also allows the
functional applications to be hosted remotely from the graphics engines and it is AGL that is defined
as an ASAAC Standard. A full definition of AGL can be seen in Annex A.

NATO UNCLASSIFIED 52
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.10 Power Management

A PCM has the capability to switch power on/off from other CFM’s, thus allowing CFM’s to be
powered up and down in a controlled fashion. This section deals with the services necessary to
control the power switches.

The ASAAC Power management concept offers three possible solutions to how these switches might
be managed. The solution chosen by any programme would be entirely at the discretion of the system
designer. They are:

- Application Controlled,

- GSM Controlled,

- MLI Controlled.

The PCM MSL contains ‘power switching’ services (available at the APOS and MOS) enabling it drive
a bank of power switches and it is these switches that are responsible for switching power on/off the
other CFM’s in the rack.

Table 6 - Power Switching Services

setPowerSwitch Switch power on/off to a module.

resetPowerSwitch Reset the power switch (switch all modules off)

getPowerSwitchStatus Get the current status of the power switch

These services are only applicable for the application controlled or GSM controlled solutions.

9.10.1 Application Controlled Solution

The PCM contains a data processor which is capable of supporting a three layer stack and
consequently it is able to host power management functional applications. These applications would
interface with the rest of the system using VC’s and could, based on information received, control the
power switches using the power switching services contained within the APOS and MOS. This
method of power control is shown in Figure 30.

NATO UNCLASSIFIED 53
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.10.2 GSM Controlled Solution

Application Layer PCM

Power
Management
Application
OSL

APOS
MSL
OS
MOS

Power Switching
Services

Figure 30 - Application Control

As we have already mentioned in the previous section, the DP on the PCM is capable of hosting a
TLS and with that comes the OSL complete with GSM functionality.

The RE Level GSM resident on a PCM, is a GSM just like any other. Consequently it takes its place in
the System Management hierarchy and as with any other RE GSM, it is controlled by a super ordinate
GSM.

NATO UNCLASSIFIED 54
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Superordinate GSM

PCM Stop, Stopped,

Load, Loaded,
RTBP
Run Running
2 1 Mode Switches
. Power Switch Data
.
Power Switch Data
OS A 1101010011
RE B 1101011111
GSM C 1110101011
CM D 1111010111
E 1111101101
F 1111011011
3 G 1101011111
. Power Switch Data

Power Switching part of MSL

Specific to PCMs

Figure 31 - PCM Management (Example)

The GSM at RE level shall control the power switch settings based upon information it retrieves from
the RTBP in response to ‘mode change requests’ it receives from its super ordinate GSM. Each
request to change mode received by the PCM GSM would result in it getting the relevant CFM
switching information for that mode from the RTBP and then passing it on to the OS using the power
switching services made available within the APOS.

9.10.3 MLI Controlled Solution

The aim of the Power Management via MLI is to have a PCM capable to manage the turn on/off
switching at MSL level without involving upper layers on PCM i.e. OSL and AL. The PCM supporting
this capability may be implemented with either only the MSL or the whole TLS.

9.10.3.1 PCM Configuration

The GSM at IA or AC levels on a distant CFM shall manage the PCM Power Switches configuration.
Reading the RTBP, the GSM sends Power Switches configuration data using the SMOS service
requestDownloadToCfm with the service Id LOAD_POWER_CONFIGURATION and checks the
return status. See section 11.7 SMOS. The OS and the MSL transform this service into MLI
messages.

To configure the PCM the following operations are performed:

- The CFM sends the Power Switches configuration data to the PCM in an MLI Message,

- The CFM receives the status of the previous operation onto the PCM on an MLI Message.

NATO UNCLASSIFIED 55
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.10.3.2 Power Health Monitoring

The Power Management via MLI shall provide services to monitor the Power Supply and Switching
capabilities.

The GSM at IA or AC levels uses the SMOS service getRemoteInfo with the service Id
POWER_STATUS. The OS sends an MLI request to the PCM. A message, with the status of all
switches is replied. See section 11.7 SMOS.

9.11 Network Management

9.11.1 Network Definition

The ASAAC architecture is independent of the selected Network technology and the technology
dependency is encapsulated into blueprints, which contains data dependent of the Network
technology / implementation.

A Network shall use a single technology throughout. The physical nature of a Network is dependent
on the implementation technology.

It shall be noticed two different types of Networks:

- Network for module-internal communication, i.e. IPC, IPEC and IMC, which is described in the
MSL section 10.4.2,

- Network for module-external communication, i.e. BMC, which is described is the present section.

9.11.2 Network Configuration

Network configuration means the process of configuring the NSM and the network capabilities for any
CFM using the network. The NSM supports routing capabilities of the Network.

9.11.2.1 Configuration of the CFM Network Capability

The CFM at power up time is silent and is able to receive a Message from the Network onto a default
TC.

The CFM’s receive the MLI Message Routing Table (see section 12.7.2.2.2.2), which configures the
CFM access to the Network during the initialisation phase.

The GSM at IA or AC levels that manages the CFM, shall read the blueprints, and then shall send
Routing Table using the SMOS service requestDownloadToCfm with the service Id
LOAD_ROUTING_TABLE to the CFM to be configured. The routing table information defines the type
of routing configuration operation it is required to perform within the CFM.

This capability is important because it provides flexibility at initialisation time allowing any Module set
up and running to manage the initialisation of the others. See section 12.7, MLI.

After the CFM initialisation, when it is set up and running with a complete TLS, the GSM may
configure the Network capability of the CFM in using the dedicated SMOS then MOS services. See
section 10.4.2 MSL Communication Capability.

NATO UNCLASSIFIED 56
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.11.2.2 Configuration of the NSM

An NSM is started with a default configuration, which is dependent on the network technology applied.
This default configuration sets up a default routing scheme that allows as minimum the configuration
of the NSM at the very beginning of system initialisation. Then the NSM is able to receive a
configuration from an external CFM.

The GSM at IA or AC levels manage the Network Configuration. Reading the RTBP, the GSM sends
configuration data using the SMOS service requestDownloadToCfm with the service Id
LOAD_NETWORK_CONFIGURATION via the connected link between the CFM and the NSM. See
section 11.7.8.1.

To configure the NSM the following operations are performed: (In the following text the numbers (1),
(2) and (3) identify the messages in the Figure 32)

- The CFM sends the ASAAC switch configuration data (1) to the NSM.

- The Message comprises all necessary headers to pass through the network switch (Message
Network Header), to reach the end point in the NSM/MSL (TC Header) and finally to be
interpreted by the SCU (MLI Header).

- The SCU receives the ASAAC switch configuration data (2). Then, it translates these data into the
Network switch configuration data, which are understandable by the switch.

- The SCU sends the Network switch configuration data (3) to the switch.

CFM

AL
NSM
SMOS sendLocalInfo

OS
OS
OSL RTBP GSM Switch

Switch Control Unit

MSL MLI Interpretation

Cbit error

(1) (3)
NIU
NIU NIU
NIU
(2)

Figure 32 - Configuration of a NSM

NATO UNCLASSIFIED 57
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

(1) and (2)

Message
Message (3)
Network Header
Network Header
Configuration
Configuration
TC Header
TC Header Network Header
Network Header

MLI Header
MLI Header Network Switch
Configuration
ASAAC Switch Data
Configuration
Data

Figure 33 - Network Configuration Message Format

9.11.3 Network Health Monitoring

The Network Management provides services to monitor the Network communication capabilities.

The GSM at RE level is able to check whether the hosting CFM has its network interface resource
onto the NIU is sane in using the SMOS then the MOS services getNetworkPortStatus. See
section 11.5.1.3.6 and 11.7.4.4.

The GSM at IA or AC levels may be able to check all remote end-point communication either
internally (. e.g. a PE in the same CFM) or externally (. e.g. a PE in a distant CFM) to the CFM. The
GSM uses the SMOS service getRemoteInfo with the service Id TEST_MESSAGE. This test
mechanism is based on an MLI message on TC. The TC is an end-point wherever in a CFM. It may
be either a remote MSU or a remote PE. See section 11.7.8.2.

The GSM at IA or AC levels is able to retrieve the status of the whole Network. The GSM shall use
the SMOS service getRemoteInfo with the service Id NETWORK_STATUS. Actually the OS sends an
MLI request to the NSM. A message, with the status of all ports physically connected up to the NSM,
is replied. See section 11.7.8.2.

9.11.4 Network Technology Transparency

A change of Network Technology leads to a change of MSL. The components in the Layers above the
MSL shall be independent of the Network Technology due to the NII, which ensures that
independency. It means their implementation shall be valid whatever the choice of the Network. At
that level a change of Network shall only imply the change of the Network configuration data within
the blueprints if necessary.

The change of the Network Topology shall not have an impact on the MSL implementation of the
CFM. At a level above the MSL a change of Network Topology shall imply the change of the Network
configuration data within the blueprints.

NATO UNCLASSIFIED 58
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

9.12 Time Management

The specified time management is based on synchronisation without convergence. Time

Management and handling involves all TLS layers:

- The MSL, responsible for:

- Providing the time through the MOS interface,

- Clock initialisation, synchronisation and updating.

- The OSL:

- The GSM, responsible for the configuration and the Fault Management of the Time,

- The RTBP, containing information related to the Time Management,

- The OS, bridging between the MSL and the APOS client or the GSM.

- The AL, using the APOS Time services.

The Time Management is based on three time references, a hierarchy of Clocks, and the
management of the Clock on each CFM.

9.12.1 Time References

The three time references supported by the Time Management Concept are:

- Absolute Global Time (AGT),

- Absolute Local Time (ALT),

- Relative Local Time (RLT).

9.12.1.1 Absolute Global Time (AGT)

This is essentially the time of day, universally known both inside and outside the aircraft and therefore
inside and outside an IMA system. Absolute global time is usually provided in terms of year, month,
day, hour, minute and second, with fractional seconds if required, and is usually local to the current
time zone (e.g. GMT).

The resolution and accuracy will be constrained by that of data transmitted to the aircraft from sources
such as GPS.

The concept for the Absolute Global Time specifies that this time reference shall be:

- Supplied to the IMA system one or several times,

- Distributed to all the Common Functional Modules (CFM) within the IMA system,

- Supplied to the AL and the OSL.

9.12.1.2 Absolute Local Time (ALT)

The Absolute Local Time is the system time reference within an IMA processing system. ALT shall be
initialised upon the occurrence of a system event such as the application of power. ALT will have a

NATO UNCLASSIFIED 59
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

higher resolution than AGT, and as such, it may be used by functional applications requiring high
levels of synchronisation such as the implementation of multiple redundant processing lanes.

The concept for the Absolute Local Time specifies that this time reference shall be:

- Local to the IMA system,

- Maintained from a logically central time reference source,

- Distributed/synchronised throughout the CFM’s that form the IMA System to cope with the system
(global) time resolution requirement,

- Exhibiting no discontinuities, i.e. the clock shall not jump forwards or backwards,

- Distributed/synchronised using a hierarchy of clocks,

- Independent from the AGT,

- Supplied to the AL and the OSL.

9.12.1.3 Relative Local Time (RLT)

Relative Local Time is local to a CFM and can be of a higher resolution than the two other time
references. RLT is used:

- For close synchronisation of tightly coupled computing processes and scheduling,

- Possibly to synchronise to a particular event in the system,

- Made available to the OSL and AL through the use of MOS and APOS services.

The concept for the Relative Local Time specifies that this time reference shall be independent from
the ALT.

9.12.2 Clock Hierarchy

Each CFM shall host a clock. The clock concept defines several clocks that will be used to build a
hierarchy for the purpose of managing a time reference throughout the system.

During the system initialisation process, blueprint information shall determine the position of a
particular clock in the hierarchy in terms of it assuming the functionality of either a:

- Master Reference Clock (MRC),

- Reference Clock (RC), or

- Module Clock (MC).

An example is shown in Figure 34.

NATO UNCLASSIFIED 60
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MRC
MRC
(CFM)
(CFM)

MC
MC MC
MC
(CFM) (CFM)
(CFM) (CFM)

RC
RC RC
RC
(CFM) (CFM)
(CFM) (CFM)

RC
RC
(CFM)
(CFM)
MC
MC MC
MC MC
MC MC
MC MC
MC
(CFM) (CFM) (CFM) (CFM) (CFM)
(CFM) (CFM) (CFM) (CFM) (CFM)

MC
MC MC MC
MC
(CFM)
MC (CFM)
(CFM) (CFM) (CFM)
(CFM)

Figure 34 - Clock Hierarchy in an ASAAC System

The Clock hierarchy is designed for each implementation. The basic rules of this hierarchy are:

- The MRC shall be unique in the Time hierarchy. It is the highest level of the hierarchy. It shall be
able to be in charge of several RC or MC.

- The RC shall be under the control of an upper Clock that may be an RC or an MRC. It shall be
able to be in charge of several RC or MC.

- The MC shall be under the control of an upper Clock that may be an RC or an MRC. It is the
lowest level of the hierarchy.

9.12.3 Clock Configuration

The GSM is responsible for configuring the clock on the basis of RTBP information. See SMOS
service configureClock (11.7.9.1) and MOS service configureClock (11.5.1.2.1.4). The configuration of
the clock comprises:

- Clock Mode: MRC, RC, or MC,

- The TC to communicate with the upper clock (MRC or RC). If the Clock is itself an MRC, it shall
be the TC’s to communicate with the external source.

- All necessary information for the algorithm of the clock synchronisation

The configuration of the Federated Clocks (SMOS service attachFederatedClock, section 11.7.9.2,
and MOS service attachFederatedClock, section 11.5.1.2.1.5) to the Clock on this CFM comprises:

- The identification of these Federated Clocks,

- The TC’s to communicate with the Federated Clocks.

The configuration of the Clock is performed once. The configuration of the Federated Clocks may be
multiple (MRC or RC) or never done (MC), it depends on the Clock hierarchy.

NATO UNCLASSIFIED 61
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If the CFM does not have a TLS and only an MSL available, the Clock is remotely configured with an
MLI message (MLI message Time Configuration, section 12.7.2.2.3.1), which is initiated by a GSM
onto a distant CFM.

9.12.4 Clock Management

The MSL is responsible of the clock management. That Management gathers all functionalities that
allow the providing of the three reference times to the APOS client through the MOS interface. They
are identified as:

- The Clock initialisation,

- The Clock distribution/synchronisation and updating (see section 12.7.2.2.3).

The Clock Management depends on which mode it is configured and which Time references it is
managing.

The Time references are initialised in several steps that are:

1. Power up,

2. GSM configuration,

3. Time distribution.

At power up the availability of different clocks is:

- RLT: it may be initialised and available if the dedicated hardware resource is set up and running,

- ALT: As the GSM is not set up and running yet. The ALT is set as unavailable,

- AGT: Same as ALT.

Then the GSM has configured the clock in a particular mode. The initialisation of the ALT and AGT
starts depending on the Clock Mode.

- MRC: the ALT is initialised, then ready to be provided. The AGT is requested from an external
source,

- RC: The ALT and the AGT are requested from the upper Clock,

- MC: Same as RC.

When the AGT and ALT are initialised and available in the MRC, they may be distributed through the
clock hierarchy.

NATO UNCLASSIFIED 62
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10 Software Architecture Definition

Table 7 defines the process classes, the associated layer, and the respective interfaces for the
ASAAC software architecture illustrated in Figure 3 and Figure 35. ‘P’ indicates interface providers
and ‘U’ indicates interface users.

Application Layer
System
Management

Functional Application
Application Management

APOS

Operating System Layer

Operating SMOS Generic System SMBP

Management Runtime
System
blueprints

MOS

Module Support Layer

Figure 35 - Software Architecture

Table 7 - Layers, Process Classes, and Standardised Interfaces

Layer Process Class MOS APOS SMOS SMBP SMLI GLI OLI MLI

Functional
Application - U - - - - - -
AL
Application
Manager - U - - PU - - -
OS U P P - - - PU U
OSL
GSM - U U U PU PU - -
- RTBP - - - P - - - -

NATO UNCLASSIFIED 63
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MSL - P - - - - - - PU

The “functional application” processes and “application manager” processes are also summarised by
the term “Application Process”.

Note: All processes, which have no visibility of the APOS interface depend on MOS services, and
may also utilise OS internal services.

10.4 MSL

10.4.1 MSL Module Management

The MOS (Module to OS Interface) shall encapsulate the hardware architecture of a given CFM
(Common Functional Module). The encapsulation shall be provided using defined function calls. The
function calls shall comprise communication and board resource services. OS’s may need additional
optional MOS services. The services defined for an ASAAC CFM are defined in section 11.5. The
location of the MOS inside a CFM is shown in the Figure 36.

Figure 36 - ASAAC Software Stack on a CFM

The functions implemented by the MSL and visible at the MOS or MLI (Module Logical Interface see
section 12.7) comprise:

- PE local functions:

- Timer Functions,

- Device Services,

- Callback Services,

- BIT,

NATO UNCLASSIFIED 64
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- CFM Resource Services,

- NII Services.

- CFM global functions:

- CFM Boot Functions,

- CFM Initialisation,

- MLI Protocol,

- CFM BIT,

- CFM SW Load (via MLI),

- Internal/External Communication Management,

- Logging,

- Time Management.

10.4.2 MSL Communication Capability

The MSL communication capability is hardware dependent. It is standardised the items that are
externally seen by other ASAAC components on the same CFM or on another CFM. Those items are:

- The NII: The upper layer uses services of the MOS interface for communicating that are
independent on the technology used within the MSL. This subset of the MOS interface dedicated
to the communication purpose is the NII.

- The TC: The communication means of the MSL is the TC. This object is allocated below the NII,
and the upper layer handles it through NII services.

- The MLI messages: A CFM is able to control a remote CFM at MSL level.

10.4.2.1 Network Independent Interface

The role of the NII is:

- To provide a standard communication interface within an ASAAC system,

- To make the network implementation and the OS implementation independent of each other,

- To provide access to the NW independent of the network technology applied.

The NII provides the following services:

configureInterface (...) Configures a local interface to the network.

configureTransfer (…) Configures the local resources to handle a transfer.

receiveTransfer (…) Collects data received from a sender.

sendTransfer (…) Sends data.

NATO UNCLASSIFIED 65
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

destroyTransfer (…) Releases the local resources for a transfer.

getNetworkPortStatus (…) Gets locally stored network information.

Extension services have been identified to support some signal processing applications (e.g.
RADAR). They are listed in the following table:

ConfigureFragmentedTransfers (…) Provides to the MSL the distribution and collection laws
associated to fragmented transfers

SendFragmentedTransfer( ) Performs a fragment transfer, which is equivalent to a multicast

transfer sending portions of the buffer to send to destinations

ReceiveFragmentedTransfer(…) Collects portions of buffers received from several sources

10.4.2.2 TC

10.4.2.2.1 Identification

Within the MSL Communications, three types of identifiers are used in addressing and routing:

- TC identifier,

- Network identifier,

- Interface identifier.

10.4.2.2.1.1 TC identifier

Each TC is identified throughout the system by a unique TC identifier, and is the same at all
terminations of the TC. Exceptionally, non-unique TC identifiers may be used locally where required,
e.g. during initialisation (See section 10.4.2.2.4).

10.4.2.2.1.2 Network identifier

Each connection between the Network and the CFM is identified throughout the system by a unique
Network Identifier, which is specified as part of the NetworkDescriptor structure. The
NetworkDescriptor consists of two elements:

- Network, which is a value used to identify a particular Network and is unique within the ASAAC
System,

- Port, which is used to identify a port connected to a Network and is a unique value within that
Network.

Each of the internal and external networks or communication mechanisms is identified as a Network.
The CFM is connected up to external Network through NIU. The internal parts of the CFM are
connected to an internal Network through the RU.

The NetworkDescriptor value is configurable and given by the blueprints.

NATO UNCLASSIFIED 66
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The scope over which the network and port parameters are unique depends on the scope of the
particular network:

- For a BMC Network, while the network parameter must be unique within the system, the port
parameter need only be unique within the module,

- For an IMC Network, both parameters must be unique within the module,

- For an IPEC Network, both parameters must be unique within the PE,

- For the IPC Network, nominal values are used for both parameters.

10.4.2.2.1.3 Interface identifier

Interfaces of various forms are used for both module-external communication, over the
communication network, and module-internal communication. Interfaces include NIU using for the
communication network for BMC, and RU for IMC.

An interface on a PE is unique within that PE. Interfaces on NIU and RU are unique within the
Module.

The interface identifier value of a physical interface in the module is permanent and given by the
specification of the MSL.

10.4.2.2.2 Configuration

All these identifiers are specified within the blueprints. The OSL handles the blueprints and shall
configure the MSL in using the NII configuration services. That configuration is done in two stages:

1. The configureInterface service maps the interface identifier (not modifiable within the
MSL) to a NetworkDescriptor (modifiable within the blueprints) and configures the interface
devices that may be spread on the PU, MSU and NIU. After this operation, all interfaces have a
unique identifier when they are seen from the NII.

2. The configureTranfer service maps the NetworkDescriptor to a TC identifier, and

configures the necessary TC resources at the interface specified by the NetworkDescriptor. In
repeating this service, it is possible to configure the departure point, the arrival point and the
intermediate points within the module. In that way, the entire routing path is set up. In BMC, the
Network routing Information is set up at the NIU interface point.

10.4.2.2.3 TC end-point

A TC has two or more (for multi-cast) end-points that may be either on the same Module or on
different Modules. They determine the departure point and the arrival point of the TC. It shall be
noticed that this end-point may be either:

- The NII: in that case TC messages are performed with the NII services sendTransfer and
receiveTransfer,

- Within the MSL: The message is directly performed by the MSL. The upper layer is not notified
and cannot access to the message. This type of end-point shall be used for performing MLI
services.

NATO UNCLASSIFIED 67
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.4.2.2.4 Default Routing

By default any TC is received by the module. There is no further routing inside the module unless a
routing table is received.

By default any CFM is quiet unless it has received a Routing Table.

The initial transfer of a routing table is provided in a single message in accordance with the MLI
protocol.

10.4.2.3 Module Logical Interface

The Module Logical Interface (MLI) is a communication mechanism for holding a dialog between two
MSL layers. This Logical Interface leads to the interoperability of Modules. This Logical Interface is
based onto TC.

It comprises:

- The TC Header of transmitting Messages onto the Network,

- Services that are performed by a remote MSL,

- Network Properties, which are specified in detail in document [1].

The services supported by this logical interface are:

- CFM Resources Management, providing a means of managing a remote CFM (particularly one
with only an MSL resident). This may involve retrieving data from or remotely testing such a CFM.
The type of services provided are:

- PBIT result,

- CFM Info,

- CFM Status,

- CFM Communication Test.

- Download Management, providing a means by which software or configuration information can be

loaded from a CFM/PE with a complete TLS to a remote PE or MSU with only a MSL resident.
The type of services provided are:

- Load image,

- Load Routing Table.

- Time Management, providing a means of distributing/synchronising time between CFM’s.

- Power Switch Management, providing a means of managing a remote PCM (particularly one with
only an MSL resident),

- Network Management, providing a means of managing a remote NSM.

Details on MLI are specified in section 12.7.

NATO UNCLASSIFIED 68
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.4.3 Resident Software

A part of the MSL or the whole MSL shall be stored on every CFM. It shall be identified as the
Resident Software. It shall support the boot and initialisation of the module.

Details on the Resident Software are fully specified in the CFM standard (refer to document [2]).

10.5 OSL

10.5.1 GSM

10.5.1.1 Introduction

The GSM is the generic part of the system management that is organised in three levels as a
hierarchy. The GSM is instantiated at these three levels:

- Aircraft (AC) level,

- Integration Area (IA) level,

- Resource Element (RE) level.

For more details about this hierarchy refer to section 4.1 System Management Function.

The GSM of each level is divided into four main functions:

- Health Monitoring

- Fault Management

- Configuration Management

- Security Management

This breakdown does not drive to a Software design but allows identifying behaviour and involved
interfaces per functions and levels.

10.5.1.2 GSM Interfaces

GSM's operating at different levels within the system management hierarchy shall communicate with
each other via a logical interface referred to as the GLI. This interface in effect provides
communication paths between the different instances of GSM from the Aircraft Level to RE Level,
passing by possible IA Level.

NATO UNCLASSIFIED 69
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 37 - GSM Logical Interface

This figure introduces the interactions between GSM at different levels as an example and highlights
requirements in the following sections.

External Interfaces:

The external interfaces of the GSM are the Application to OS Interface – APOS, the System
Management to OS Interface – SMOS, the System Management to Blueprints Interface – SMBP, and
the GSM Logical Interface – SMLI (Figure 38):

AC
SMOS SM HM CM SMBP
FM
APOS SMLI

IA
SMOS SMBP
SM HM FM CM
APOS SMLI

RE
SMOS SMBP
SM HM FM CM
APOS

Figure 38 - GSM: External Interfaces

NATO UNCLASSIFIED 70
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.1.3 RE Level

The GSM at RE Level shall be responsible of managing the Resource Element that hosts it in
providing the four main functions.

It shall be under the control of a unique super-ordinate GSM that may be at IA or AC level.

10.5.1.3.1 Configuration Management

It shall receive the configuration to be applied from its super-ordinate Configuration Management via
the GLI, or its AM via SMLI or the associated Fault Management.

It shall report its super-ordinate Configuration Management for configuration change.

It shall obtain configuration data from the RTBP in term of:

- Process and thread configuration,

- Network Port configuration,

- Time Management.

It shall request the OS to apply the configuration data via the dedicated SMOS service.

Table 8 - List of SMOS Services for RE-CM

Service Group SMOS Call RTBP Table

Process and createProcess PROCESS_ITEM

Thread createThread THREAD_ITEM

Configuration runProcess PROCESS_SET

stopProcess PROCESS_SET

destroyProcess PROCESS_SET

setSchedulingParameters SCHEDULING_ITEM

VC createVirtualChannel VC_SET

Configuration destroyVirtualChannel VC_SET

attachChannelToProcessOrThread VCMAPPING_ITEM

detachAllThreadsOfProcessFromVc VCMAPPING_ITEM

attachTransferConnectionToVirtualChannel VC2TCMAPPING_SET

detachTransferConnectionFromVirtualChannel VC2TCMAPPING_SET

Network Port configureInterface INTERFACE_SET

Configuration createTC TC_SET

NATO UNCLASSIFIED 71
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group SMOS Call RTBP Table

destroyTC TC_SET

Time configureClock CLOCK_ITEM

Management attachFederatedClock FEDERATED_

CLOCK_ITEM

10.5.1.3.2 Health Monitoring

It shall maintain the health status of the RE via the SMOS services related to the BIT Management.

It shall reply its health status to its super-ordinate Health Monitoring when required.

It shall collect error reports from the OS

It shall get from the RTBP information for processing the error confirmation.

It shall notify the associated Fault Management when an error is confirmed.

Table 9 - List of SMOS Services for RE-HM

Service Group SMOS Call

Fault Management getError

Built-In Test getPbitResult

Management startCbit

getCbitResult

10.5.1.3.3 Fault Management

It shall receive confirmed errors from the associated Health Monitoring.

It shall access to RTBP in order to get the actions to be performed for the confirmed error. The
actions to be performed may be:

- Discard the error,

- Localise the fault in the RE,

- Activate the error handler of a Process,

- Instruct the associated Configuration Management to perform a reconfiguration,

- Perform actions for the Integrated Test Maintenance,

- Report the error to the super-ordinate Health Monitoring.

It shall log all types of Message following RTBP actions. Fault Management maintains the
error/message log, as logging is performed via the GSM. Specific areas of memory may be allocated
for different purposes e.g. errors, maintenance, and system moding or events.

NATO UNCLASSIFIED 72
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table 10 - List of SMOS Services for RE-FM

Service Group SMOS Call

Fault Management ActivateErrorHandler

Network Management getNetworkPortStatus

CFM Information getMyCfmStatus

getMyCfmInfo

getMyPeId

Built-In Test startIbit

Management getIbitResult

10.5.1.3.4 Security Management

During configuration of an RE, the RE-GSM-SM accesses the RTBP in order to ascertain whether
protectively marked data is to be processed on this particular PE. If it is, the RE-GSM-SM then enters
a dialogue with its subordinate SM in order to take receipt of the encryption and authentication keys it
will require during the mission.

During normal operation, the RE-GSM-SM will be required to encrypt, decrypt and authenticate any
data sent to it by its OS. The actual action performed on the data will be defined from data retrieved
from the RTBP during the configuration process.

If the RE-GSM-SM is not able to decrypt or validate the authentication of an item of data, it may send
a message via the GLI to its superordinate GSM-SM.

Table 11 - List of SMOS Services for RE-SM

Service Group SMOS Call

Security getPMData

Management returnPMData

getAuditData

erasePhysicalMemory

10.5.1.4 IA Level

The GSM at IA Level shall be responsible of the generic part of the system management of an
Integration Area in providing the four main functions.

It shall be under the control of a unique super-ordinate GSM that may be at IA or AC level.

It shall control at least one subordinate GSM that may be at IA or RE level.

It may be associated with an AM.

NATO UNCLASSIFIED 73
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.1.4.1 Configuration Management

It shall receive the configuration to be applied from its super-ordinate Configuration Management via
the GLI, or its AM via SMLI or the associated Fault Management.

It shall report its super-ordinate Configuration Management for configuration change.

It shall receive configuration change from its subordinate Configuration Managements.

It shall distribute mode change/reconfiguration requests to each of its subordinate Configuration

Managements in accordance with instructions sent to it by either its super-ordinate Configuration
Management or its AM.

It shall manage the initialisation phase of associated CFM’s, which may be PCFM, NSM and PCM, in
terms of:

- Getting the PBIT result,

- Getting the CFM Status,

- Downloading image or configuration data.

It shall be responsible of the Power Management and the Network Management for its set of
subsequent CFM’s.

Table 12 - List of SMOS Services for IA-CM

Service Group SMOS Call RTBP Table

CFM Resources RequestDownloadToCfm CFM_ITEM or PE_ITEM

Management getRemoteInfo CFM_ITEM or PE_ITEM

10.5.1.4.2 Health Monitoring

It shall maintain the health status of the IA via the dedicated GLI Messages (Are you/I am alive).

It shall reply its health status to its super-ordinate Health Monitoring when required.

It shall receive fault reports from its subordinate Fault Managements.

It shall get from the RTBP information for processing the error consolidation and then its confirmation.

It shall notify the associated Fault Management when an error is confirmed.

10.5.1.4.3 Fault Management

It shall receive confirmed errors from the associated Health Monitoring.

It shall access to RTBP in order to get the actions to be performed for the confirmed error. It may
perform the following actions:

- Discard the error,

- Localise the fault in the IA,

NATO UNCLASSIFIED 74
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Instruct the associated Configuration Management to perform a reconfiguration,

- Report the error to the super-ordinate Health Monitoring.

Table 13 - List of SMOS Services for IA-FM

Service Group SMOS Call RTBP Table

CFM Resources Management getRemoteInfo CFM_ITEM or PE_ITEM

10.5.1.4.4 Security Management

The IA-GSM-SM is capable of acting as an interface between the superordinate GSM-SM and their
subordinate GSM-SM.

10.5.1.5 AC Level

The GSM at AC Level shall be responsible of the generic part of the system management of an IMA
System in providing the four main functions.

It shall control at least one subordinate GSM that may be at IA or RE level.

It may be associated with an AM.

10.5.1.5.1 Configuration Management

It shall receive the configuration to be applied from either its AM via SMLI or the associated Fault
Management.

It shall receive a configuration change from its subordinate Configuration Managements.

It shall distribute mode change/reconfiguration requests to each of its subordinate Configuration

Managements in accordance with instructions sent to it by its AM.

It shall manage the initialisation phase of subsequent CFM’s acting like an IA-CM.

10.5.1.5.2 Health Monitoring

It shall maintain the health status of the IMA System via the dedicated GLI Messages (Are you/I am
alive).

It shall receive fault reports from its subordinate Fault Managements.

It shall get from the RTBP information for processing the error consolidation and then its confirmation.

It shall notify the associated Fault Management when an error is confirmed.

10.5.1.5.3 Fault Management

It shall receive confirmed errors from the associated Health Monitoring.

It shall access to RTBP in order to get the actions to be performed for the confirmed error. It may
perform the following actions:

NATO UNCLASSIFIED 75
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Discard the error,

- Localise the fault on the IMA System,

- Instruct the associated Configuration Management to perform a reconfiguration.

Table 14 - List of SMOS Services for AC-FM

Service Group SMOS Call RTBP Table

CFM Resources Management getRemoteInfo CFM_ITEM or PE_ITEM

10.5.2 OS Functions
The ASAAC OS primarily provides the abstraction required for a resource element. It further defines
the interface services required for the integration of a resource element within the ASAAC core and
for system management.

This section describes the OS functions and defines the interface functions required. The OS
functions are grouped into six classes:

1. Basic OS Functions,

2. Communication Functions,

3. Application Services,

4. OS Error Handling,

5. OLI Services,

6. GSM Services,

7. CFM Control Services.

These six groups of OS functions are generic for any ASAAC OS, regardless of the module type.
Additionally, there are specific functions for the MMM and the PCM modules:

8. MMM File Services,

9. MMM File Access Server,

10. PCM Power Switch Services.

10.5.2.1 Basic OS Services

The basic functions of the OS focus on the management of the following resources:

- Processing time, associated with the processor resources that are provided by a processing
element,

- Elapsed time, associated with the resources of absolute time, i.e. real-time, and

- Memory resources.

The OS functions, which are associated with these resources, are:

NATO UNCLASSIFIED 76
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Scheduling Management (consisting of execution control and real-time control), and

- Process Management.

10.5.2.1.1 Scheduling Management

A thread of control (a thread) is an independent sequence of execution of program code inside a

process. A thread has defined temporal characteristics that are derived from the application temporal
characteristics:

- A thread executes within the address space of its associated process, and shares storage and
code areas with the other threads belonging to the same process.

- A thread possesses its own context (i.e. separate stack and processor register settings).

- A thread shall be pre-emptable with the exception of critical areas, which are protected against
pre-emption.

- A thread communicates with other threads of the same process via semaphores, events, and
VC’s.

- A thread communicates with threads of other processes via VC’s.

- Thread scheduling may be based on absolute local time in order to allow implicit thread
synchronisation within the given time accuracy across process borders.

- An application thread invokes OS functions exclusively via the APOS interface.

- A thread within a GSM process may in addition invoke OS functions via the SMOS interface.

Scheduling Management
Initialisation

Real-time Control

DORMANT
Release point stopThread
startThread
stopThread

READY End of waiting, Time-out WAITING

sleep
waitForSemaphore
schedule receiveMessage
suspendSelf

RUNNING
terminateSelf
Execution Control

Figure 39 - Thread State Transition Diagram with sample APOS services

NATO UNCLASSIFIED 77
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The individual thread states are:

- Dormant
the thread is ineligible to receive resources. A thread is in the dormant state before it is started
and after it is terminated (or stopped).

- Ready
the thread is eligible for scheduling. A thread is in the ready state if it can be executed but is not
'Running'.

- Running
the thread is currently executing on the processor. Only one thread can be executing at a time (on
each processor).

- Waiting
the thread is not allowed to receive resources until a particular event occurs (message, time out,
etc.).

Table 15 describes in rows the departure state and in columns the arrival state. The character ‘-‘
means the transition shall be forbidden; otherwise, it is the number defining the condition of state
transition that is described in the Table 16.
Table 15 – Transition of Thread States

Dormant Ready Running Waiting

Dormant
- 1 - -
Ready 2 - 5 -
Running 3 4 - 6
Waiting 2 7 - -

Table 16 – Condition of State Transition

Number Condition
1. When the running thread calls the APOS service startThread, thus starting the
thread.
2. When the running thread calls the APOS service stopThread, thus stopping the
thread.
3. When the running thread stops by its own with the APOS terminateSelf.
4. When the running thread waits on APOS sleep of zero or is pre-empted by
another thread within the process.
5. When the thread is selected for execution by the OS scheduler
6. There are four alternatives:

- The running thread suspends itself calling the APOS service suspendSelf,

- The running thread attempts to access a resource (semaphore, event, VC

message, OS buffer VC message, file, OS file buffer) with a blocking call
and the resource is currently not available,

- The running thread has called the APOS service sleep or sleepUntil,

- The running thread waits on an SMOS blocking call.

7. Either when the resource that the thread was awaiting becomes available or

NATO UNCLASSIFIED 78
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Number Condition
the time-out expires.
If this is a periodic thread waiting on its period, the OS scheduler places it in
the new state when the awaited release point is reached.

10.5.2.1.1.1 Execution Control

As the GSM, which initiates a process, does not have control of the scheduler, a special thread in the
process, the main thread, gets started at the transition of process ‘INITIALISED’ state to process
‘RUNNING’ state, while all other threads in the process are started in the DORMANT state. The main
thread then takes control immediately after the process has been initiated and may start other threads
within the same process.

The purpose of execution control is to share the processing resources between a set of threads,
which are eligible for execution (thread status is either ‘READY’ or ‘RUNNING’). This is illustrated by
Figure 39, which shows the thread states in a state transition diagram classifying the transitions into
distinct responsibilities. The purpose of execution control is to select one out of a set of ‘READY’
threads, and to transfer it into the ‘RUNNING’ state according to a particular scheduling scheme.
Equally, another thread that may have been ‘RUNNING’ is transferred to the ‘READY’ state. The
applied scheduling scheme is not standardised. An OS may even provide multiple scheduling
schemes. Examples for scheduling schemes include:

- Priority based pre-emptive scheduling,

- Cyclic Executive,

- Earliest deadline first.

The selection of scheduling schemes is project dependent.

Characteristics

a) The OS shall provide at least one scheduling scheme.

b) Execution Control shall select one or none thread out of a set of scheduled threads for execution.
This shall be done in accordance with the scheduling scheme selected and the scheduling
parameters provided.

c) The scheduling of threads shall be independent of the association of threads to processes.

d) The scheduling scheme shall be selectable by the GSM function.

e) Each implemented OS scheduling scheme shall be associated with a set of scheduling

parameters, which are valid for the selected scheduling scheme and the set of threads provided
by a process.

f) Unless the scheduling parameters and the scheduling scheme for a thread are defined, a thread
shall not be scheduled.

10.5.2.1.1.2 Real-time Control

Real-time control is the part of Scheduling Management that relates execution control with the real-
time behaviour required for the individual threads. In order to be able to provide time safe operation of
the application functions, it is required to define the real-time constraints of application thread
execution. Real-time control is performed in accordance with a real-time control scheme. This scheme
defines times and conditions for a thread to become included into the set of scheduled threads
(release point), and the time after which a runtime exception is raised, if a thread has not completed

NATO UNCLASSIFIED 79
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

its activity (deadline). The release point and the deadline define the real-time constraints within any
real-time control scheme. The way, release points and deadlines are expressed depending on the
selected real-time control scheme. The real-time control scheme is not standardised. Examples for
real-time control schemes include:

- Event triggered execution (e.g. arrival of a VC message),

- Time triggered execution (e.g. absolute local time),

- Periodic (e.g. Rate monotonic scheduling).

Either the Application Process or the OS may include the real-time control function. If an Application
Process includes the real-time control scheme, the OS real-time control function is not required. The
OS real time control will then be limited to a situation, where no release points and deadlines are
defined. Within the implementation of the Application Process, assumptions about the applied
scheduling scheme have to be made.

Characteristics:

a) A thread shall be transferred from the ‘WAITING’ state to the ‘READY’ state, if its release
point is encountered.

b) The OS shall monitor the timing resources associated with a thread (elapsed time resources =
deadline, processor time resources = budget).

c) A violation of any real-time constraints associated with a single thread shall cause the OS to
raise a “Real-time Exception” associated with that thread. If no real-time constraints are associated
with a thread, this exception is not required.

10.5.2.1.1.3 Thread Services

The following APOS and SMOS services are used to control threads (for detailed description refer to
section 10.7 and 11.7.1):

- APOS getMyThreadId

- APOS getThreadStatus

- APOS startThread

- APOS stopThread

- APOS terminateSelf

- APOS suspendSelf

- APOS lockThreadPreemption

- APOS unlockThreadPreemption

- APOS sleep

- APOS sleepUntil

- SMOS createThread

- SMOS setSchedulingParameters

NATO UNCLASSIFIED 80
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.1.2 Process Management

A process is a container entity, which encapsulates executable object code without external
references. It encloses one or more threads including all memory resources required by threads,
global data, and communication buffers.

The primary attributes of a process are its identity, a file of executable object code, and its memory
space requirements. The identity of a process is unique within the system and shall identify the
individual function assigned to that process within the context of the system.

A set of secondary attributes controls the behaviour of the code inside the process. Processes are
classified into two categories:

- Application processes, and

- System processes (GSM processes and OS).

The process is associated with a main thread and optionally with additional threads. The set of
additional threads should include an error handler thread. The error handler thread may be invoked by
the system fault management function in order to complement system error handling at the
application level. Additionally, a scheduling policy is assigned with each process.

The general properties of a process determine its behaviour:

- Each process has its own, static memory space that is not accessible by any other process.

- Processes have no attributable, temporal characteristics.

- Processes are not scheduled (see threads in section 10.5.2.1.1).

- Processes are single or multi-threaded.

- Processes communicate with other processes via VC’s.

- The VC’s used are attributes of a particular process.

- Processes are predictable in terms of memory consumption.

- A process executes on a single Resource Element.

- Every process has at least one thread (the main thread).

- Every process may have an error handler thread.

- A process has the states Stopped, Running and Initialised.

10.5.2.1.2.1 Process Control

Process control is determined by the states of a process as illustrated in Figure 40:

NATO UNCLASSIFIED 81
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

runProcess

attachChannelToProcessThread
Running
Stopped

detachAllThreadsOfProcessFromVc
stopProcess

destroyProcess

setSchedulingParameters

createThread
runProcess

createProcess

attachChannelToProcessThread
Initialised

detachAllThreadsOfProcessFromVc

destroyProcess

setSchedulingParameters

Figure 40 - Process State Diagram

The process states provides three separate modes:

- Initialised:
Configuration mode of the process. This is the default state of a process, when it is created. In
this state threads may be created, scheduling parameters may be loaded, VC’s may attached or
detached from the process. Scheduling of threads is disabled.

- Running:
Operational mode of the process. The configuration of the process cannot be changed.
Scheduling of threads is enabled.

- Stopped:
Scheduling of threads is disabled.

Characteristics

a) Scheduling for all the threads associated with a process shall be disabled when the process is
in the ‘STOPPED’ or ‘INITIALISED’ state regardless of value of scheduling parameters.

NATO UNCLASSIFIED 82
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

b) SMOS configuration associated with a process shall be applicable only if this process is in the
‘STOPPED’ or ‘INITIALISED’ state.

c) SMOS creation of a thread shall be applicable only if this process is in the ‘INITIALISED’
state.

d) Scheduling for all the threads associated with a process shall be enabled when the process is
in the ‘RUNNING’ state. The scheduling is performed in accordance with the scheduling parameters.

10.5.2.1.2.2 Memory Management

The OS manages all memory resources provided by the processing element. There are two main
kinds of memory. There is memory that is required by the OS itself in order to perform its functions
(e.g. VC management or scheduling). Additional memory is required by all functions that are external
to the OS. The memory requirements for these functions are described by the process abstraction. A
process encapsulates a bounded amount of memory. The memory limitations of a process are pre-
determined, upon the creation of a process. For safety reasons, the memory areas of the OS and the
individual processes are protected against each other. The process abstraction is used for all kinds of
functional applications and for the GSM functions. It is not available for the functions provided by the
MSL.

Characteristics

a) The OS shall maintain its own memory area.

b) The OS shall maintain separate memory areas for each process.

c) Memory areas shall be protected against each other.

d) The OS shall manage parallel execution contexts as associated with threads.

e) Whenever a violation of the memory area assigned to either OS or processes occurs, the OS
shall raise a “Memory Violation Exception”.

10.5.2.1.2.3 Process Services

The following SMOS services are used to control Processes (for detailed description, refer to section
11.7.1):

- SMOS createProcess

- SMOS destroyProcess

- SMOS runProcess

- SMOS stopProcess

As all process services operate on global data they shall protect themselves against pre-emption in
order to preserve data integrity of these data items.

10.5.2.2 Communication Functions

The OS communication capability is dependent on the OS design. It is standardised with respect to

the items that are externally seen by other ASAAC components on the same CFM or another CFM.
Those items are:

NATO UNCLASSIFIED 83
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- The VC: The VC is a communication object that handles communication between processes.

- The SMOS services related to the communication: The GSM is responsible of the management of
the communication objects VC and TC.

- The APOS VC services: The AL uses VC services of the APOS interface for communicating.

- The OLI: An OS is able to hold a dialog with another OS in using the OLI.

10.5.2.2.1 VC

10.5.2.2.1.1 Properties

The properties are:

- A VC is a communication object supported by the OS.

- A VC is a communication object that enables VC users not to be aware of the location of each
other.

- A VC is an abstraction, which enables the application to be independent of the system

architecture (i.e. the sender does not need to be aware of the physical location of the receiver(s))
so as to provide for portability and reconfiguration.

- The VC features are completely described in the blueprints in terms of direction, number and size
of buffer, and behaviour (e.g. 1:1 or multicast).

- A VC is created, configured, destroyed, attached, and detached to TC and/or process by the OS

on the initiative of the GSM, which manages this based on Blueprint data.

- A VC enables the sender and the receiver(s) to work asynchronously from the data transfer
activity, which is handled by the OS. This implies buffering.

- A VC is defined as a one-way path that specifies the sending point and the receiving point(s).
(Another VC may only provide a return path.)

- The VC’s running on a system are assumed to be independent from each other in terms of
memory resource allocation and logical behaviour.

- A VC supports two types of behaviour, which shall be selected by a parameter within the
blueprints:

- 1 to N FIFO, see section 10.5.2.2.1.2,

- 1 to N history receiver, see section 10.5.2.2.1.3.

NATO UNCLASSIFIED 84
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.2.1.2 VC behaviour type 1 to N FIFO

Number of buffers
Number of buffers specified by BluePrints
specified by BluePrints
Communication
TC Receiver 1
manager
Emitter 1 Communication
TC Network 2 local buffers
manager
Communication
3 local buffers TC Receiver 2
manager
4 local buffers
FiFo of management for
receiver buffers.
FiFo of management for
receiver buffers.
Rules of management for
sender buffers specified
by blue prints.
Service access point.

Figure 41 - Example for a 1 to N FIFO

The aim of this type of VC is to provide for a reliable means of transmission, no loss being permitted,
from a sender thread to one or more receiving threads.

The receiver and sender buffers are managed in a first in first out logic.

The sender does not block, and it is able to transmit data to its receivers even if one of the receivers
does not read the data on that VC.

Note: Depending on the parameters specified for this type of VC, and if one of the receivers does not
read the data on that VC, the sender may be unable to send any data on the VC or an error occurs.

10.5.2.2.1.3 VC behaviour type 1 to N LIFO

Number of buffers
Number of buffers specified by BluePrints
specified by BluePrints
Communication
TC Receiver 1
manager
Emitter 1 Communication
TC 2 local buffers
manager Network
Communication
3 local buffers TC Receiver 2
manager
4 local buffers

Rules of management for LiFo management for

sender buffers specified received buffers
by blue prints.

Service access point.

Figure 42 - Example for a 1 to N LIFO

The aim of this kind of a VC is to provide for a reliable means of updating a transmission history to
receiver(s).

The receiver accepts the messages in a buffer in a last in first out order.

Each time the receiver reads the VC it will receive the newest unread message.

NATO UNCLASSIFIED 85
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The sender shall not wait on buffer availability. Lack of buffer resource on sender side shall raise an
error.

The sender does not block, and it is able to transmit data to its receivers even if one of the receivers
does not read the data on that VC.

Note: The behaviour of this type of VC requires the application to include some sort of sequencing
data to the message (e.g.: data validity time stamp, or sequencing number) to enable the receiver to
detect whether the data it is consuming is the latest value or a historical message.

10.5.2.2.1.4 Identification

Within the OS Communications, two identifiers specify the VC:

- A Global VC identifier that is unique throughout the system, and is the same at all terminations of
the VC identifies a VC. This information is located within the blueprints.

- From the application point of view, a Local VC identifier that is unique within this one identifies the
VC. This Identifier is absolutely not related of the design of all other application. That allows not
knowing the location of the other application.

10.5.2.2.2 Communication Management

10.5.2.2.2.1 SMOS Services

The GSM is responsible for the communication management based on information within the
blueprints. The OS provides the GSM with a set of services in the SMOS interface.

This set is split in two categories:

- Services related to the TC management.

configureInterface (...) Configures an interface in the MSL.

configureTransfer (…) Configures a TC in the MSL

destroyTransfer (…) Releases the local resources for a TC in the MSL.

getNetworkPortStatus (…) Gets from the MSL locally stored network information.

- Services related to the VC management.

createVirtualChannel (...) Creates a new global VC Object

destroyVirtualChannel (…) Destroys the specified VC

attachTransferConnectionToVirtualChannel (…) Maps a TC to a VC.

detachVcFromTc (…) Removes mapping of a VC on a TC,

attachChannelToProcess Thread (…) Maps a VC to a Process

NATO UNCLASSIFIED 86
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

detachAllThreadsOfProcessFromVC (…) To release attachment of a VC to all threads of a

Process.

10.5.2.2.2.2 Configuration

Global and Local VC Identifiers are both specified within the blueprints. The GSM handles the
blueprints and shall initiate the OS to configure the Communication. That configuration is done in
three stages:

- TC Configuration: The GSM initiates the OS to manage TC.

- VC Configuration: The resources of the VC object are allocated, but the VC not active yet.

- Routing: The attachment is split into two parts. First the attachment of the VC on a TC (If a TC is
needed). Then the attachment to the Process Application, the
AttachVirtualChannelToProcess service maps the global VC identifier (unique within the
System) to the local VC identifer (unique within the Process)

10.5.2.2.2.3 Runtime

There are three types of VC messages, which are discriminated, by means of the VC info (as defined
by blueprints).

- APOS VC:
During Runtime messages being sent on an APOS VC shall be attached with a VC header and
mapped to a global VC; any message received on a global VC shall be mapped onto processes
and threads and the VC headers shall be stripped off.

- OLI VC:
An OLI VC shall be identified by means of its type definition in the SMBP structure VcDescription.

- Raw VC:
During Runtime messages being sent on a raw VC shall be mapped to a global VC; a raw VC
message received on a global VC shall be mapped onto a single process thread. The mapping of
raw VC is constrained to a single receiver.

When a global VC message is being sent through the NII, it shall be mapped on one or more TC’s
associated with that global VC. When a TC message is received at the NII it shall be associated with
the relevant global VC.

10.5.2.2.3 APOS VC Services

APOS Services related to VC make the Application Processes independent of the location of the
other. Additionally, the Application Processes have any information about the VC features they are
using.

The APOS VC Services are split in two categories:

- Services handling the message buffer within the AL,

sendMessageNonblocking (...) Sends a message via a specified VC without blocking the caller.

receiveMessageNonblocking (…) Reads a message from the specified VC, if available, and returns
immediately without blocking the caller

NATO UNCLASSIFIED 87
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

sendMessage (…) Sends a message via the specified VC blocking the caller.

receiveMessage (…) Awaits, blocking the caller, until a message is received on the
specified VC.

waitOnMultiChannel (…) Waits on several VC’s for messages to arrive (on receive
channels) or/and for sending buffers to be freed (on transmit
channels).

- Services handling the message buffer within the OS.

lockBuffer (…) Obtains a reference to a buffer from the OS to be sent over a VC

using sendBuffer.

sendBuffer (…) Sends a previously requested and locked buffer on a VC.

receiveBuffer (…) Waits until a new buffer is received or a time-out occurs

unlockBuffer (…) Releases a buffer back to the OS

10.5.2.3 Application Services

Application functions are mapped to Application Processes. The OS services are offered to the
Application Process at the APOS interface. There are five main groups of functions, which are
accessible through the APOS interface:

- Time Services,

- Thread Control,

- Synchronisation,

- Communication,

- Error Handling.

These services are available for every resource element regardless of the module type the resource
element is mapped to. The file handling function is only available for resource elements of the type
Mass Memory Module.

The following subsections describe each of these functions in detail.

10.5.2.3.1 Time Services

The OS provides time services for the application functions. There are two kinds of times that are
provided by the OS.

NATO UNCLASSIFIED 88
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table 17 - Properties of Time Services

Time Service Properties Accuracy

System time.
As absolute local time may be used for
Homogeneous within the whole time triggered thread execution, the
Absolute Local Time
system. accuracy of absolute local time is
defined by the platform functions.
Provided by CFM service.

Module local time.

The accuracy of relative local time is
Relative Local Time Provided by CFM service.
defined by CFM functions.
Inhomogeneous time.

Universal Time
The accuracy of absolute global time is
Absolute Global Time
Homogeneous within the whole defined by the aircraft functions.
aircraft.

The associated clocks are provided by the CFM board services.

These are the APOS time services (for detailed description, refer to section 11.4.2):

- APOS getAbsoluteLocalTime

- APOS getRelativeLocalTime

- APOS getAbsoluteGlobalTime

10.5.2.3.2 Thread Synchronisation

Application processes may require synchronisation services in special situations. For instance it may
be required to sequentialise access to process local data between threads or to synchronise the
execution of threads to a certain event.

The OS shall provide two separate means of synchronisation, namely semaphores and events. These
mechanisms can be used only within a single process.

The utilisation of semaphores is restricted to pre-emptive scheduling schemes.

10.5.2.3.2.1 Semaphores

Semaphores are an abstract signalling mechanism reflecting the utilisation of shared resources.
Given a bounded set of shared resources, a counting semaphore provides a locking mechanism for
such a set of resources. It is initiated to a value reflecting the number of available resources. As long
as a resource is available, a lock is immediately achieved and the counter is decremented. When a
lock is returned, the counter is incremented again. If all resources are locked, the requesting thread is
transferred into the ‘WAITING’ state and placed into a queue together with other threads waiting for
the same semaphore. When a semaphore is returned, the next thread from that queue achieves the
lock and is transferred back to the ‘READY’ state.

Characteristics

NATO UNCLASSIFIED 89
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

a) The semaphore shall be associated with a counter. The counter is initialised to a value
reflecting the number of resources available.

b) The semaphore’s counter shall be decremented whenever a semaphore lock is achieved.

c) As long as the counter value is greater than zero, a semaphore lock shall be immediately
achieved.

d) When the counter value has reached zero, it shall not be decremented any more. The
requesting thread shall be transferred into a ‘WAITING’ state and shall be placed into a queue
of waiting threads.

e) The queue of waiting threads shall provide either FIFO behaviour or priority queue behaviour.
The priority shall refer to the scheduling priority as defined by the scheduling parameters,
which are associated with the thread.

f) When a semaphore lock is returned, the next output from the queue of waiting threads shall
obtain the lock, and shall be transferred into the ‘READY’ state.

g) If the queue of waiting threads is empty, the counter that is associated with the semaphore
shall be incremented up to a predetermined maximum value reflecting the amount of
resources controlled by the semaphore.

h) Semaphores shall be identified by means of a name.

i) The scope of semaphore identification shall be limited to a single process.

Note that the use of priority based queuing depends on the thread-scheduling scheme, and may not
be portable between resource elements using different scheduling schemes.

The following APOS services are associated with Semaphore activities:

- APOS createSemaphore

- APOS deleteSemaphore

- APOS waitForSemaphore

- APOS postSemaphore

- APOS getSemaphoreStatus

- APOS getSemaphoreId

10.5.2.3.2.2 Events

The event mechanism is another signalling mechanism, providing an abstraction of a process global
condition. The event indicates whether a condition is satisfied or not. Threads may wait for a condition
to be satisfied.

Characteristics

a) An event condition shall only be valid within the scope of a single process.

b) If an event condition is not set, a thread shall be transferred to the ‘WAITING’ state for a
bounded amount of elapsed time until the event condition is set.

NATO UNCLASSIFIED 90
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

c) If an event condition is set, all threads, which are waiting for this particular event condition,
shall be transferred back into the ‘READY’ state.

d) Events shall be identified by means of a name.

e) The visibility scope of an event shall be limited to a single process.

The following APOS services are associated with Event handling:

- APOS createEvent

- APOS deleteEvent

- APOS setEvent

- APOS resetEvent

- APOS waitForEvent

- APOS getEventStatus

- APOS getEventId

10.5.2.3.2.3 Error Handling

The application error handling covers Application Process related (i.e. implementation related) fault
management and fault management in the domain of application functions (i.e. function related). In
either case, the dedicated entity for error handling is the GSM (refer to section 10.5.1). All errors
occurring, whether it is a hardware error, an OS exception or an application error, are collected by the
GSM function. The GSM fault localisation or fault masking procedures may delegate dedicated sub-
functions to Application Processes. Any Application Process may have a dedicated thread for the
error handling, the error handler thread. This thread is controlled by the GSM function, and is outside
the scope of control of the Application Process itself. The error handler thread has exclusive access to
the APOS error handling services except raiseApplicationError, which can be used by any thread.

Characteristics

a) An Application Process may provide a special error handler thread.

b) The error handler thread shall be initialised in the ‘DORMANT’ state.

c) The error handler thread, when started, shall be transferred into the ‘READY’ state. It shall be
scheduled like any other thread.

d) When the error handler thread completes its execution, it shall be transferred into the
‘DORMANT’ state.

The following APOS services are associated with Error handling:

- APOS logMessage

- APOS raiseApplicationError

- APOS getErrorInformation

- APOS terminateErrorHandler

NATO UNCLASSIFIED 91
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.4 OS Error Handling

10.5.2.4.1 Overview

The OS error handling differs according to the error originator. Three types of OS Error Handling are
identified:

- Application Error

- OS Error

- MSL Error

An error identifies both the detected fault and the Fault Detection Mechanism that has detected it as
well.

The OS, which notifies the GSM, first collects all errors related to Application Processes, OS and
MSL.

Then the GSM decides, according to the Fault Handling policy that is described within the blueprints,
the relevant actions to be performed. It may either

- Wait for another error

- Discard it

- Perform the actions that are described within the blueprints.

10.5.2.4.2 Application Error

10.5.2.4.2.1 Principle

An Application Process may raise an Application Error in the following situations:

- The return code of an APOS service,

- The expired time-out of a blocking service,

- The Analysis of data provided by another Application Process.

The Application provides the OS with the error. Then the OS forwards it to the GSM that decides of
the next actions, which may be the activation of the Error Handler.

10.5.2.4.2.2 Detailed sequence

A detailed sequence is specified below

NATO UNCLASSIFIED 92
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Error Handler Faulty Thread OS GSM

2. The OS builds the

error report

APOS raiseApplicationError

1. A thread notif ies the OS

with an Error by APOS
raiseApplicationError SMOS getError

3. The OS prov ides the GSM with

an error report by releasing the
SMOS blocking serv ice getError.

4. According to the Fault

Management policy the
GSM decides whether the
Error Handler shall be
inv oked
5. The GSM requests
the activ ation of error
handler

7. The Error Handler is

perf ormed. Error Inf ormation are
retrieved with
getErrorInf ormation. SMOS activateErrorHandler

APOS getErrorInf ormation 6. The OS shedules the

Application Error Handler.

8. The Error Handler is

completed and return
status 9. The OS releases the
SMOS blocking service
activ ateErrorHandler

ReturnStatus

Figure 43 - OS Error Handling of an Application Error

1. A thread in an Application Process raises an error. This error is notified to the OS by APOS
raiseErrorApplication. The error is specified by:

- An error code that identifies both an error and the Fault Detection Mechanism that has detected it.

- An error message

2. The OS builds an error report with Application Error information and additionally:

- Global Process Id of the Application that has raised the error,

- Faulty Thread Id of the thread that has called APOS service raiseErrorApplication.

3. The OS releases SMOS blocking service getError thus the GSM retrieves the error report.

4. According to the Fault Handling policy within the blueprints, the GSM may request the activation of
application error handler (SMOS service activateErrorHandler) to the OS. This point is stressed in the
rest of the sequence.

5. The GSM thread that has called the SMOS service activateErrorHandler is blocked.

6. The OS schedules the application error handler.

NATO UNCLASSIFIED 93
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

7. The application error handler retrieves the error code with APOS getErrorInformation service.

8. The error handler processes the Application error then passes its return status to the OS via the
APOS terminateErrorHandler service.

9. The OS releases the GSM thread that is blocked on the SMOS service activateErrorHandler.

10.5.2.4.2.3 Application Error Handler Features

The Application Error Handler is optional. If it is used it shall be defined in the blueprints and shall be
created at Application process creation time as any other application thread.

It shall be activated when GSM initiates the OS. It is identified as the Thread number zero.

The Error Handler shall not use blocking services and shall provide its return code to the OS.

The error handler shall terminate with the APOS service terminateErrorHandler that provides the OS
with the status of the error processing. When the Error Handler has terminated, it can be restarted by
a new SMOS activateErrorHandler.

10.5.2.4.3 MSL Error

MSL OS GSM

2. The OS builds the error

MOS service report

1. The OS performs a MOS

service. An error is detected
in checking the MOS return
code.

SMOS getError

3. The OS provides the GSM

with an error report by releasing
the SMOS blocking service
getError.

4. According to the Fault

Management policy the
GSM performs actions

Figure 44 - OS Error Handling of an MSL Error Due to a Return of a MOS Service

An MSL Error is invoked according to:

- The return code of a MOS service (see Figure 44), or

- A CBIT error that is notified by the MSL to the OS when an error occurs during a CBIT test (see
Figure 45).

NATO UNCLASSIFIED 94
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MSL OS GSM

2. The OS builds the

report
error
Notify Error

1. The CBIT is performed.

An error is notified to the OS 3. The OS releases provides
the
GSM with an error report
by
releasing the SMOS
blocking
service
getError.

SMOS getError

4. According to the Fault

Management policy the
GSM performs actions

MOS SMOS
getCbitResult getCbitResult

5. The GSM retrieves the

CBIT result

6. The GSM assesses the

CBIT result

Figure 45 - OS Error Handling of an MSL Error Due to a CBIT Status

1. If an error occurs during a CBIT, the OS is notified (see section 9.4.4.2).

2. The OS builds an error report with CBIT Error information.

3. The OS releases SMOS blocking service getError thus the GSM retrieves the error report.

4. According to the Fault Handling policy within the blueprints, the GSM may request more information
about the CBIT error. This point is stressed in the rest of the sequence.

5. The GSM performs the SMOS service getCbitResult then the OS performs the MOS service
getCbitResult.

6. The GSM assesses the CBIT result and may perform additional actions.

10.5.2.4.4 OS Error

The OS errors are split in two classes:

- Error related to Application,

- Error specific to the OS.

NATO UNCLASSIFIED 95
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.4.4.1 Error related to Application

In certain cases the applications cannot directly handle an error although it has impact on the
application behaviour and it has to be processed by the Application.

Three cases are identified:

- A Real-time exception. When a thread violates its real-time constraints (if defined), the OS shall
detect this error.

- An Application Error within an APOS service. The APOS services do not necessarily return the
error status to the Application. In this case the OS shall directly pass the error to the GSM.

- An OS Exception occurring during Application execution, e.g. Memory violation, divide-by-zero.

For the error cases that are described in this section, the error handling is identical to the one
described in section 10.5.2.4.2. This application error handler may be invoked as described in the
referred section.

10.5.2.4.4.2 Error specific to the OS

An OS Error could be invoked according to:

- An internal error occurring in the OS, e.g. in the VC communication processing

- An OS Exception occurring during OS execution, e.g. Memory violation, divide by zero,

The detailed sequence is:

1. An OS component raises an error.

2. The OS builds an error report.

3. The OS releases SMOS blocking service getError thus the GSM retrieves the error report.

4. According to the Fault Handling policy within the blueprints, the GSM performs actions that it has
read in blueprints.

10.5.2.5 OLI Services

The OLI describes the intercommunications between two instantiations of OS’s as shown in Figure
46.

NATO UNCLASSIFIED 96
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Application
ApplicationLayer
Layer Application
ApplicationLayer
Layer Application
ApplicationLayer
Layer

OLI OLI OLI OLI

Operating
Operating System
System Layer Operating System Operating
Operating System
System Layer

Module
ModuleSupport
SupportLayer
Layer Module
ModuleSupport
SupportLayer
Layer Module
ModuleSupport
SupportLayer
Layer

Figure 46 - The OLI

Figure 47 identifies those protocols that comprise the OLI.

Operating
Operating System
System Layer
Layer Operating
Operating System
System Layer
Layer
OLI Virtual channel
Virtual channel Virtual channel

OLI Presentation
DATA Presentation DATA Presentation

Module
ModuleSupport
Support Layer
Layer Module
ModuleSupport
Support Layer
Layer

MLI
Transfer channel Transfer channel

Figure 47 - Decomposition for OLI

For MLI, see section 12.7.

The OS Logical Interface (OLI) is a communication mechanism between two OS instances. These OS
instances are located on two PE that may be on the same or different CFM. The OLI ensures the
interoperability of OS. It comprises:

- The VC Header of transmitting Messages onto the Network,

- Services that are performed by a remote OS

The services supported by this logical interface are:

- Application Download Management, providing a means by which a PE loads Application

Processes via a remote MMM/PE.

NATO UNCLASSIFIED 97
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- MLI Download File Management, providing a means by which a PE requests a remote MMM/PE
to load a File onto a third CFM by using the MLI Service. Three types of file download are
identified:

- MLI Download Image

- MLI Routing Table

- MLI Network Configuration

10.5.2.6 GSM Services

The GSM functions (refer to section 10.5.1) relevant to the OS are the control of remote modules
(CFM), the control of the resources associated with the local resource element, and the control of the
resources provided by the local CFM.

The main functions provided by the OS in order to facilitate the GSM Functions are:

- Resource Element services:

The GSM configuration management requires these services to control the resources associated
with the resource element level.

- Security services:
The GSM resource element level security management requires services for encryption,
decryption, authentication and services for collection and logging of Audit data.

- Error Handling services:

The GSM resource element level fault management requires services for error monitoring and
error handling.

- Remote CFM services:

The GSM module control functions included at aircraft and integration area levels require services
for module initialisation and for the retrieval of module information.

10.5.2.6.1 Resource Element Services

The OS provides an abstraction for a resource element. It therefore provides all services required for
the GSM to control local resources. There is a standardised set of resources provided by the ASAAC
OS.

10.5.2.6.1.1 Characteristics

The OS shall manage all objects that are related with the memory, execution flow and communication
resources associated with a resource element:

- Process (refer to section 10.5.2.1.2.3),

- Thread (refer to section 10.5.2.1.1.3),

- VC (refer to section 10.5.2.2),

- Communication Nodes (refer to section 10.5.2.2),

- TC configuration at a Communication Node (refer to section 10.5.2.2),

- Link of a VC with a process and a thread (refer to section 10.5.2.2),

NATO UNCLASSIFIED 98
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Link of a VC with a TC (refer to section 10.5.2.2).

10.5.2.6.2 Security

When a functional Application Process outputs data, it writes the data to a local VC. It is the
responsibility of the OS to attach the data to the relevant Global VC prior to it being transmitted to
where it is required to go. Similarly, when inputting data to a functional Application Process, it is the
responsibility of the OS to take the data from a global VC and attach it to the relevant process' local
VC ready to be read by the functional application. The OS therefore requires a local / global VC
mapping data table In order to perform this functionality, the contents of which are set up as part of
the RE configuration process. In addition to this mapping data, the OS is also configured with data
that allows it to ascertain whether or not the data being transferred over a given VC is data regarded
as being protectively marked (data of a sensitive nature). Consequently, before the OS attaches any
data to a Global VC (sending data), it first determines whether the data is protectively marked and if
so sends it to the GSM Security Manager where it is either encrypted or has authentication added.
Similarly, prior to attaching data to a local VC (receiving data), the OS again determines whether it is
protectively marked and if so sends it to the GSM Security Manager where it is either decrypted or
has the authentication validated. This process is shown in Figure 23.

10.5.2.6.3 Error Handling

The following SMOS services support the error handling:

- SMOS getError

- SMOS activateErrorHandler

10.5.2.6.4 Remote CFM Services

The control of remote modules is an integral part of the GSM functions required at aircraft and
integration area levels. In order to initialise a module after power has been applied to that module, the
following sequence has to be applied:

- PBIT is retrieved from the module via the default MLI channel.

- Initialising the module routing table sets up the MLI interface of that module.

- Each PE belonging to the module is booted by providing a sequence of files via the MLI boot
channels.

After the above sequence is completed, all resource elements associated with the module are
available and can be integrated into the system management hierarchy. Further remote CFM
Configuration may be required for NSM and PCM modules, which do not integrate a resource element
as a local instance of control.

Finally, remote CFM Services are required for Fault Management at Integration area and aircraft
levels for retrieving information on CFM status and Built-In-Test results.

These operations are sub-summarised in two classes of operations:

- Provision of data to a remote CFM.

- Retrieval of status data from a remote CFM.

Each operation is based on a pair of MLI messages. The OS is managing the communication with a
remote CFM based on MLI messages.

NATO UNCLASSIFIED 99
 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.6.4.1 Provision of Data

Under control of GSM, the OS provides boot images, routing tables and network configuration files to
remote CFM’s. GSM provides all context information required, i.e. the identification of TC’s to be
used, reference to the files that contain the data to be transferred and the fragmentation size to be
used. The sending of MLI messages transferring the data to a remote CFM and receiving of
acknowledgement messages from a remote CFM is under the responsibility of the OS.

Characteristics

a) The OS shall retrieve a file that has been identified by the GSM, using file access function.

b) The OS shall build the MLI message associated with the requested transfer and send the
messages on a TC identified by GSM.

c) The OS shall receive the MLI acknowledge message from the remote CFM on a TC identified
by GSM and check the correctness of the response.

d) The fragmentation of the data being sent shall be managed in accordance with the message
protocol provided by the MLI (section 12.7).

e) In case of a missing or incorrect acknowledgement a retry may be made.

The SMOS service requestDownloadToCfm provides the required capabilities for control of remote
CFM.

10.5.2.6.4.2 Retrieval of Status Data

CFM status data is provided at the MLI interface of any CFM. It provides GSM function on a remote
CFM with information about the status of a remote CFM. GSM requests information at the SMOS
interface. The OS requests the information from a remote module by means of a MLI message. The
remote CFM returns the requested information in response to the request.

The kinds of information that can be retrieved are:

- CFM status

- PBIT result

- CBIT result

- CFM structure and capabilities (CFM Info)

Characteristics

a) The selected CFM information shall be requested by means of an MLI message to the remote
module.

b) The time period between the request and the answer shall be bounded.

c) The CFM response shall be received and provided to the GSM.

The SMOS service getRemoteInfo provides the required capabilities for retrieving information from a
remote CFM.

NATO UNCLASSIFIED 100

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

10.5.2.7 CFM Control Services

There are CFM functions that are provided by MSL services, but are required by GSM Functions,
which do not have access to the MOS. The OS maps these services on the SMOS interface, thus
providing them to GSM functions.

Characteristics

a) The OS shall map the MOS services dedicated to the control of the local module clock to
SMOS services.

b) The OS shall map the MOS services providing information about subordinate CFM clocks to
SMOS services.

c) The OS shall map the MOS services for the configuration and the deletion of TC’s to SMOS
services.

d) The OS shall map the MOS services for the configuration of Communication Nodes to SMOS
services.

e) The OS shall map the MOS service for retrieval of CFM local CBIT results to SMOS services.

The following non-communication SMOS services represent the MOS services that are mapped onto
the SMOS interface (for communication services see section 10.5.2.2.2.1):

- SMOS configureClock

- SMOS configureFederatedClock

- SMOS getMyPeId

- SMOS getCbitResult

- SMOS getPbitResult

- SMOS startCbit

- SMOS startIbit

- SMOS getIbitResult

- SMOS getMyCfmStatus

- SMOS getMyCfmInfo

- SMOS writeLog

- SMOS readLog

10.5.2.8 MMM File Services

The MMM provides module specific APOS services for accessing a file and managing a file system.
These services allow to

- Create and delete files,

- Open, read, write and close files,

NATO UNCLASSIFIED 101

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Create and delete directories.

The following APOS services are used for file access on an MMM:

- APOS createFile

- APOS deleteFile

- APOS openFile

- APOS closeFile

- APOS getFileAttributes

- APOS readFile

- APOS writeFile

- APOS createDirectory

- APOS deleteDirectory

- APOS seekFile

- APOS lockFile

- APOS unlockFile

10.5.2.9 MMM File Access Server

Under control of OLI, the MMM provides two functions:

- File Reading and

- Remote MLI File Download.

The following OLI services are used for communication with the MMM File Access Server:

- OLI Request Read File

- OLI Reply Read File

- OLI Request Remote MLI File Download

- OLI Reply Remote MLI File Download

10.5.2.10 PCM Power Switching Services

In the case of a Power Conversion Module, the OS shall provide access for GSM or applications to
power switch resources.

The following APOS services are provided for the controlling the power switches a PCM:

- APOS setPowerSwitch

- APOS resetPowerSwitches

NATO UNCLASSIFIED 102

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- APOS getPowerSwitchStatus

10.6 RTBP

10.6.1 Overview
The RTBP contain the information required by a GSM operating at the RE level of system
management to configure (instantiate functional applications, VC’s, Transfer Channels etc) and
manage (fault management and security policies) the PE on which it is hosted. In addition to this, the
RTBP’s also provide the GSM’s operating at the IA and AC levels of system management with the
information they need to manage the resources under their jurisdiction.

In all cases the GSM shall access the RTBP data across the standardised interface known as the
SMBP (System Management/Blueprint) interface.

The concept of using the RTBP’s in this manner therefore allows the standardised functionality of the
GSM's to be tailored to perform the specific behaviour required by a particular platform/mission.

10.6.2 RTBP tree

GSM
Root Process To CFM PE
Function Info Info
Mapping

Interface VC
GSM Info Mapping
Configuration
Data
Process
Info Thread
Info

Scheduling
GSM Logical VC to TC Info
Configuration Mapping
Function

Clock
Info
VC
Info
State
Machine
Federated Clock
TC Info Info

Figure 48 - RTBP Tree Concept

The RTBP are contained within a tree structure comprising a single root and multiple instances of
nodes and leaves as shown in Figure 48. The standardised SMBP services shall then be used to
navigate the tree and access the appropriate data.

Figure 48 introduces the RTBP tree. Each box contains data or leads to a lower one containing data,
each one being dedicated to a specific purpose.

NATO UNCLASSIFIED 103

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- GSM Process To Function Mapping: To map the GSM Process to the GSM Function, having the
GSM Process Identifier, the GSM Function identifier is retrieved.

- GSM Function: To segregate the tree between the different functions of the GSM. The GSM
Function Identifier is retrieved from the GSM Process To Function Mapping.

- GSM Configuration data: Configuration data for the current GSM Function.

- Logical Configuration: The Logical Configuration to be mapped by the current GSM Function.

- Interface Info: Information to configure an Interface Device.

- Process Info: Information to configure a Process.

- VC Mapping: Information regarding the mapping of a VC onto a Process

- Thread Info: Information to configure a Thread in a Process.

- Scheduling Info: Information to schedule a Thread in a Process.

- VC to TC Mapping: Information regarding the mapping of a VC onto a TC

- VC Info: Information to configure a VC.

- TC Info: Information to configure a TC.

- State Machine: Information to handle a state machine responsible for performing Fault
Management, Configuration Management and implementing Security Management comprising
the state to be reached, actions to be performed during the transition, time-out allocated to the
transition.

- CFM Info: Information to manage a remote CFM in term of initialisation.

- PE Info: Information to manage a remote PE in term of download.

- Clock Info: Information to configure the clock of the Module.

- Federated Clock Info: Information to attach a remote clock to the clock of the Module.

10.6.3 SMBP Services to Access the RTBP Tables

In order to traverse this tree, the following basic operations are required:

- Selecting a node

- Scrolling through a set and accessing iteratively data Items in this set

- Accessing directly data Items

10.6.3.1 Selecting a Node

A RTBP tree starts with a root node whose value is retrieved with a dedicated service, namely the
SMBP service getRootNode. It has to be performed prior to accessing any RTBP information.

The selection of a child node requires an identification, which is provided by the SMBP service
readNode, which takes as ‘in’ parameters a node and an identifier. With this information a node
handle specifying a particular child node is provided.

NATO UNCLASSIFIED 104

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Scrolling the RTBP tree node by node, all nodes can be reached. This scrolling may start from the
root of a chid node.

See example section of the SMBP service readNode section 11.6.2.2.

10.6.3.2 Iterative Access

Iterative access is required in case every child of a parent node is being retrieved. It provides a
sequential access to all the node handles associated to children of a given parent node. Using the
child node, either its attributes may be retrieved or further child nodes (if any) may be retrieved.

See example in section of the SMBP service getNodeId section 11.6.2.3, 11.6.2.5.

10.6.3.3 Direct Access

Direct access to RTBP information is required if an action of a state machine refers immediately to a
node, for instance a process node for a process that shall be created as part of a reconfiguration.

The SMBP service ‘getAttributes’ provides direct access to the RTBP data, when the value of the
node handle is being provided as part of the action parameters.

The SMBP service ‘readNode’ provides direct access to a RTBP node, when the value of the parent
node handle and the value of the item identifier are being provided as part of the action parameters.

See example section of the SMBP service getAttributes section 11.6.2.4.

10.7 Application Layer

10.7.1 Process Model

The process model ensures that the real-time aspects of the system can be achieved and verified. As
such, the process model reflects the requirements of an avionic application at an implementation
level. This does not mean that the design process need be constrained. Ideally, any suitable design
methodology, such as data flow or object oriented, can be applied. The description of the process
model is based on applications, although the same model is applicable for OSL processes.

Processes

A process is an address space that contains executable code for one or more threads and provides
the required system resources for those threads. Processes form the building blocks for Functional
Applications and System Management Applications.

VC’s provide an abstraction for the interaction of processes (see section 9.5.1.2).

NATO UNCLASSIFIED 105

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Process
Application 1 D

Process Process Process

A B E

Process
C

Thread
C.1
Thread
C.3
Process C

Thread
C.2

Data Flows / Virtual Channels

Figure 49 - Relation of Processes and Threads and VC’s

As illustrated by Figure 49, any application or system management functions are partitioned into
processes. The interactions between processes are mapped to VC’s.

Threads

A thread of control (a thread) is an independent sequence of execution of program code inside a

process. A thread has defined temporal characteristics that are derived from the application temporal
characteristics:

The concept of threads encapsulates the temporal characteristics of Application Processes and
system management processes. It addresses the aspects of processing resource consumption (i.e.
scheduling) and real-time behaviour of application and system management functions.

The hierarchy of the process model (refer to Figure 49) orders threads below processes and VC’s
below threads.

10.7.2 Resource Management

The process model leaves greater freedom for the design of the application architecture provided that
the application architecture is based on the three entities process, thread, and VC.

The process model is based on static resource assignment. This implies that, on the level of the
process model, each architectural element (basic resource entity) of an application can be described
by a static set of parameters reflecting the resource consumption of the associated element (Table
18):

NATO UNCLASSIFIED 106

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table 18 - Resource Parameters of Basic Resource Entities

Architectural Element Resource Parameters

Process Memory Space Consumption

Set of Threads
Set of VC’s

Thread Processor Time Consumption

VC Network Bandwidth Consumption

10.7.3 Thread Properties

The general thread properties are defined in section 10.5.2.1.1. Thread states are defined in section
10.7.3. The transitions between thread states are controlled by means of APOS services or, limited to
GSM, by means of SMOS services.

As all APOS operations with exception of getMyThreadId and getThreadStatus modify processor
global data, i.e. scheduler state, all relevant APOS operations on threads are protected against pre-
emption in order to preserve data integrity of scheduler state.

The actual scheduling properties are considered project specific. The following properties are a
recommendation:

- Thread Release,

- Control of Elapsed Time (deadline),

- Control of Execution Time (budget).

APOS thread services (see section 11.4.1) enable Application Processes to interact with threads of
the same process. Therefore, the integrity of application threads requires that the scope of thread
identifiers is limited to a single process.

10.7.4 Safety Considerations

The restrictions on the utilisation of APOS services (see section 11.4) for safety critical applications
are based on the assumption that the OSL is fully qualified for safety critical purposes. Therefore, the
focus is set on APOS services.

The applied scheduling method is assumed to behave deterministically. The applied scheduling
method could either be cyclic scheduling or priority based pre-emptive (FIFO) scheduling.

As the process model already provides pre-defined and bounded memory resources, only the timing
behaviour has to be considered with respect to safety issues. The aspects of time behaviour are:

- Application code time consumption,

- Time consumption by APOS services (OS time consumption),

- Interaction time consumption (Blocking times etc.).

These timing aspects are mapped to three criticality classes of APOS services (Table 19):

- Class A APOS services:

NATO UNCLASSIFIED 107

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Execution time is determined by application code and APOS services. This means that time
consumption induced by blocking and waiting shall be forbidden. Only APOS services with well-
defined execution times belong to this class of services.

- Class B APOS services:

Interaction between Application Processes and separate threads of execution is possible, but
blocking times are bounded. Therefore, the APOS services are also associated with bounded
execution times.

- Class C APOS services:

APOS services may be associated with unbounded (this does not mean undefined or infinite)
execution time.

The following table defines the criticality class for each APOS service:

Table 19 - Criticality Classes of APOS Services

Service Group APOS Call Class

Thread Management sleep B

sleepUntil B

terminateSelf B

getMyThreadId B

startThread B*

suspendSelf A

lockThreadPreemption B

unlockThreadPreemption B

stopThread C

getThreadStatus B

Time Management getAbsoluteLocalTime A

getRelativeLocalTime A

Synchronisation createSemaphore B

deleteSemaphore B

waitForSemaphore B

postSemaphore B

getSemaphoreStatus B

getSemaphoreId B

NATO UNCLASSIFIED 108

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group APOS Call Class

createEvent B

deleteEvent B

setEvent B

resetEvent B

waitForEvent B

getEventStatus B

getEventId B

Fault Handling logMessage B

raiseApplicationError B

getErrorInformation B

terminateErrorHandler B

Communication sendMessageNonblocking A

receiveMessageNonblocking A

sendMessage B

receiveMessage B

lockBuffer B

sendBuffer B

receiveBuffer B

unlockBuffer B

waitOnMultiChannel B

File Handling createFile C

deleteFile C

openFile C

closeFile C

getFileAttributes C

readFile C

writeFile C

NATO UNCLASSIFIED 109

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group APOS Call Class

createDirectory C

deleteDirectory C

seekFile C

lockFile C

unlockFile C

* If limited to the start-up of a process, startThread might also be used in the class 'A' domain.

In order to associate these criticality classes to safety classes, the following, simplified safety
classification is used:

- Safety critical functions:

These functions can affect the aircraft safety when operating in an undesired way; in this context,
safety is the ability of the aircraft not to be lost and/or not to make unintentional injuries to human
life (crew, ground personnel...).

- Survival critical functions:

These functions are required to ensure survival in a high threat environment.

- Mission critical functions:

a malfunction of mission critical functions does not mean a possible loss of the aircraft, but might
result to an abort of the mission.

In parallel, the following real time requirements are taken into account:

- Hard Real Time:

Any instance of execution of a function shall be associated with a well-defined time boundary.

- Soft Real Time:

The average function execution time shall be defined.

- No Real Time:
There are no well-defined execution times.

Associated with the safety classes and real time requirements, the following scheme for safety
restrictions shall be applied:

Table 20 - Safety Restriction Definitions

Hard real time Soft real time No real time

Safety critical A

Survival critical A AB ABC

Mission critical AB ABC ABC

In case only services of class 'A' are allowed, the definitions in Table 20 would constrain the
processes to the usage of one thread. This limitation could be weakened for the sake of a common

NATO UNCLASSIFIED 110

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

address space. Then the service startThread might also be used, but its usage is limited to the start-
up of the process.

The safety restrictions defined herein are necessary, but not sufficient in order to accomplish the
desired safety and real time quality. The defined safety restrictions shall be complemented by
adequate software and system design (example: the correct behaviour of a hard real time safety
critical function can only be guaranteed, if it can be ensured that all VC messages required by the
function are available before the function is started).

10.7.5 Language Considerations

A fundamental requirement for ASAAC is the language independence of applications. The use of
some programming language functionalities may be limited by the ASAAC SW interfaces and with the
constraints defined by the resource management concept. The use of libraries, for instance math
libraries, which do not interact with the OS, is not restricted.

10.7.6 Application Error Handling

The fault management concept is based on a hierarchy that allows errors to be detected and
recovered at the lowest level. Errors may:

- Be detected by application software, the OS, the MSL, or by the hardware,

- Occur at the system, IA, module, processor, process, or thread levels.

Upon detection of an error, the GSM is invoked to log the error and to initiate a recovery action. It
assigns an error level and a unique identifier to each error processed. The error levels and the
respective identifiers are defined in the blueprints.

Error levels and error types that are handled by applications include:

- System level errors:

System configuration error during system initialisation.

- IA level errors:
IA configuration error during IA initialisation.

- Process level errors:

errors during thread management,
errors during error handler thread.

- Thread level errors:

Application error raised by an application thread,
illegal OS request,
thread execution errors (overflow, memory violation...).

The application programmer should define the recovery action for thread level errors in a special error
handler thread. If this thread is present, GSM will start it under control of Blueprint information. In case
no error handler thread is implemented, the error information may be handled by the GSM.

Recovery actions for errors include:

- Ignore,

- Log the error but take no action,

- Confirm the error before action recovery,

NATO UNCLASSIFIED 111

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Stop faulty thread and re-initialise it from entry address,

- Stop faulty thread and start another thread,

- Stop faulty thread.

NATO UNCLASSIFIED 112

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11 Direct Interfaces Definitions

Note: The parameter descriptions, which are provided with the service specifications, provides the
reference to the data type (see section 13.5), the meaning of the parameter and, if applicable,
additions or restrictions of the domain values.

11.4 APOS

According to functional requirements the services are grouped into "use categories" - dependent on
the CFM types where the functions are implemented

- Core APOS Services

Available for use in all Application programmes on all CFM types

- Specific APOS Services

Used in Application programmes which execute on specific CFM’s (e.g. Power Conversion
Module, Mass Memory Module)

The comprehensive list of all APOS calls is listed below.

Table 21 - APOS Services

Service Group APOS Call Description Use Section

Thread sleep Wait for a time interval core 11.4.1.1

Management sleepUntil Wait until an absolute local time core 11.4.1.2

getMyThreadId Give the identifier of the current

core 11.4.1.3
thread

Allow the current thread to start

startThread the execution of another thread core 11.4.1.3
inside the same process

suspendSelf Suspend the current thread core 11.4.1.5

stopThread Terminate another thread of the

core 11.4.1.6
same process.

terminateSelf Terminate the current thread. core 11.4.1.7

lockThreadPreemption Disable the thread scheduling

core 11.4.1.8
within the current process

unlockThreadPreemption Enable the thread scheduling

core 11.4.1.9
within the current process

getThreadStatus Provide the current status of a

core 11.4.1.10
thread.

NATO UNCLASSIFIED 113

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group APOS Call Description Use Section

Time getAbsoluteLocalTime Return the absolute local time

core 11.4.2.1
Management value

getAbsoluteGlobalTime Return the absolute global time

core 11.4.2.2
value

getRelativeLocalTime Return the relative local time

core 11.4.2.3
value

Synchronisation createSemaphore Create a counting semaphore core 11.4.3.1

deleteSemaphore Remove a semaphore core 11.4.3.2

waitForSemaphore Wait at semaphore until

core 11.4.3.3
semaphore is available

postSemaphore Release the semaphore core 11.4.3.4

getSemaphoreStatus Get the number of callers to the

core 11.4.3.5
semaphore and other information

getSemaphoreId Get the semaphore identifier

core 11.4.3.6
when name is provided

createEvent Create an Event core 11.4.4.1

deleteEvent Remove an Event core 11.4.4.2

setEvent Set an Event core 11.4.4.3

resetEvent Reset an Event core 11.4.4.4

waitForEvent Wait for an event to be set core 11.4.4.5

getEventStatus Get the number of threads waiting

core 11.4.4.6
on the event

getEventId Get the event identifier when

core 11.4.4.7
name is provided

logMessage Write a log message to the

Error Handling core 11.4.5.1
module log.

raiseApplicationError Signal an application detected

core 11.4.5.2
error to the OSL.

Get the callback information of

getErrorInformation the Health Monitor in the error core 11.4.5.3
handler.

terminateErrorHandler Terminate execution of error

core 11.4.5.4
handler thread.

NATO UNCLASSIFIED 114

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group APOS Call Description Use Section

getDebugErrorInformation Get error information on latest

Debugging core 11.4.6.1
error for debugging purpose.

sendMessageNonblocking Send a message via VC without

Communication core 11.4.7.1
blocking the caller

receiveMessageNonblocking Read a message if available core 11.4.7.2

sendMessage Send a message via VC core 11.4.7.3

receiveMessage Await and retrieve a message via

core 11.4.7.4
VC

lockBuffer Wait until a free buffer is available

core 11.4.7.5
or a time-out occurs

sendBuffer Send the locked buffer via VC

core 11.4.7.6
without copy

receiveBuffer Wait until a new buffer is received

core 11.4.7.7
or a time-out occurs

unlockBuffer Release a buffer core 11.4.7.8

waitOnMultiChannel Wait on several VC’s for

core 11.4.7.9
messages to arrive.

File Handling createDirectory Creates a directory MMM 11.4.8.1

deleteDirectory Removes a directory MMM 11.4.8.2

createFile Creates a file. MMM 11.4.8.3

deleteFile Deletes a file. MMM 11.4.8.4

openFile Opens a file MMM 11.4.8.5

closeFile Closes a file MMM 11.4.8.6

lockFile Locks a file MMM 11.4.8.7

unlockFile Unlocks a file MMM 11.4.8.8

getFileAttributes Returns the file attributes MMM 11.4.8.9

seekFile Positions the file’s byte pointer MMM 11.4.8.10

readFile Reads data from a file MMM 11.4.8.11

writeFile Writes data to a file MMM 11.4.8.12

getFileBuffer Reserves memory for the data to MMM 11.4.8.13

be copied into when a file is either

NATO UNCLASSIFIED 115

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group APOS Call Description Use Section

read from or written to.

releaseFileBuffer Releases the file buffer memory. MMM 11.4.8.14

Power setPowerSwitch Turns power switch on/off PCM 11.4.9.1

Conversion resetPowerSwitches Turn all power switches off PCM 11.4.9.2

getPowerSwitchStatus Returns status of a power switch PCM 11.4.9.3

11.4.1 Thread Management Services

11.4.1.1 sleep

Purpose:

Suspend the execution of the calling thread for a given period of time.

Syntax:

ReturnStatus sleep (
in TimeInterval timeout );
Description:

The service sleep shall cause the calling thread to be transferred from ‘RUNNING’ into the ‘WAITING’
state. After the timeout interval has expired, the thread shall be transferred back into the ‘READY’
state.

A zero timeout causes the thread to be transferred immediately into the ‘READY’ state.

The service shall return ‘SUCCESS’, if the thread has been transferred to the ‘READY’ state after the
specified time.

The service shall return ‘ERROR’, when the specified timeout is negative.

The service shall return 'ERROR', when the service returns before the end of the specified delay for
an unknown reason.

Service ‘sleep’ may be used for:

- Delaying execution of a thread, e.g. to slow down the response that is provided by the calling
thread.

- Freeing processor resources during a waiting phase, when the calling thread waits for a certain
condition to occur.

The timeout value given is a lower boundary for the actual period between calling the sleep service
and resuming the ‘RUNNING’ state. This actual delay is dependent on the scheduler implementation
and the processor load imposed by other threads with equal or higher priority.

Parameter Description:

NATO UNCLASSIFIED 116

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

timeout

Data Type Definition TimeInterval

Description The timeout parameter specifies the time period for which the calling thread is held in
the ‘WAITING’ state.

A timeout value of zero causes the calling thread to be immediately transferred from
the ‘RUNNING’ state into the ‘READY’ state.

Domain Values timeout  0.0

Prerequisite Conditions:

The service sleep shall not be used within an application error handler thread.

Associated Calls:

- sleepUntil,

- suspendSelf.

11.4.1.2 sleepUntil

Purpose:

Suspend the execution of the calling thread until a given absolute local time.

Syntax:

ReturnStatus sleepUntil (
in Time absolute_local_time );
Description:

The service sleepUntil shall cause the calling thread to be transferred from the ‘RUNNING’ into the
‘WAITING’ state if the absolute local time value given has not yet passed. After the given absolute
local time has been reached, the thread shall be transferred back into the ‘READY’ state.

If the specified time has already passed, the thread will be transferred immediately into the ‘READY’
state.

The service shall return ‘SUCCESS’, if the thread has been transferred to the ‘READY’ state at
specified time or the specified time has already passed.

The service shall return ‘ERROR, when absolute local time is not available.

The service shall return 'ERROR', when the service returns before the specified absolute local time
for an unknown reason.

The service ‘sleepUntil’ may be used for:

- Time synchronisation of threads (as absolute local time is a system time);

- Jitter free periodic execution of periodic threads as start times refer to absolute time.

Parameter Description:

NATO UNCLASSIFIED 117

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

absolute_local_time

Data Type Definition Time

Description The caller provides the absolute local time value until which the thread calling the
service sleepUntil shall be kept in the ‘WAITING’ state.

Domain Values There is no limitation for this service.

Prerequisite Conditions:

The service sleepUntil shall not be used within an application error handler thread.

Associated Calls:

- sleep,

- suspendSelf.

11.4.1.3 getMyThreadId

Purpose:

Return the thread identifier, which is local to the process, of the calling thread.

Syntax:

ReturnStatus getMyThreadId (
out PublicId thread_id ) ;
Description:

A process identifier together with a thread identifier, whose scope is limited to the process, identifies
every thread. This service returns the process local thread id.

The return status shall be ‘SUCCESS’ on successful completion, otherwise an ‘ERROR’ condition
shall be returned.

Parameter Description:

thread_id

Data Type Definition PublicId

Description The thread identifier is a public identifier, being used by an APOS client and defined
in the blueprints, enumerating the threads associated with a process. The thread
shall identify a created thread, i.e. a thread that is defined in the blueprints.

Domain Values No limitation for this service.

Prerequisite Conditions:

None.

Associated Calls:

None.

NATO UNCLASSIFIED 118

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.4.1.4 startThread

Purpose:

Initialise a thread and add it to the set of scheduled threads.

Syntax:

ReturnStatus startThread (
in PublicId thread_id ) ;
Description:

This service shall initialise all attributes of a thread to their default values, reset the run-time stack of
the thread and transfer the thread into the ‘WAITING’ state. When the thread’s release point is
reached, the OS shall place the thread into the ‘READY’ state. If the real-time control does not define
a release point for the thread, this service shall transfer the thread immediately into the ‘READY’
state.

Release points (see section 10.7.3) may be defined as time triggered (e.g. periodic) or event triggered
(e.g. succeeding the reception of a VC Message). A thread’s release policy applies only after a thread
has been started. For a thread in the ‘DORMANT’ state, it does not apply.

The thread’s scheduling parameters consist of parameters that control the scheduling behaviour
directly (e.g. scheduling priority or periodicity) and parameters imposing real-time constraints on the
thread’s execution. These real-time constraints, for instance deadlines or execution budgets, require
monitoring. This service shall also initialise and start the monitoring of the thread’s real-time
constraints.

The service startThread may have an indirect impact on pre-emption as the set of scheduled threads
is modified. The thread calling the startThread service, which is obviously currently in the ‘RUNNING’
state may be placed into the ‘READY’ state at event of a re-scheduling of another thread with higher
precedence.

The service startThread returns ‘SUCCESS’ if the thread is in the ‘DORMANT’ state in the beginning,
the thread’s resources are available and the thread’s attributes are consistently set.

It shall return ‘ERROR’ if either the thread was not in the ‘DORMANT state before, if thread resources
are not available or if thread attributes are inconsistently set.

The service startThread is used at the start-up of a process by the main thread of the process to start
other threads. It may also be used by a dispatcher function implemented within the process.

Parameter Description:

thread_id

Data Type Definition PublicId

Description The thread identifier is a public identifier, used by an APOS client and defined in the
blueprints, enumerating the threads associated with a process. The thread shall
identify a created thread, i.e. a thread that is defined in the blueprints.

Domain Values No limitation for this service.

Prerequisite Conditions:

This service applies only to threads that are in the ‘DORMANT’ state.

Associated Calls:

NATO UNCLASSIFIED 119

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- stopThread,

- terminateSelf.

11.4.1.5 suspendSelf

Purpose:

Suspend the execution of the calling thread until its next release point.

Syntax:

ReturnStatus suspendSelf () ;
Description:

The service shall transfer the calling thread from the ‘RUNNING’ state into the ‘WAITING’ state. The
scheduler shall resume the thread when its release condition, specified by its scheduling parameters,
occurs. However, if there is no explicit release condition specified for the thread or the release
condition is already true, then the scheduler shall transfer the thread into ‘READY’ state.

The return status shall be ‘SUCCESS’ on successful completion. If the pre-emption is locked an
‘ERROR’ condition shall be returned and the thread stays in the ‘RUNNING’ state.

Parameter Description:

No parameters are required.

Prerequisite Conditions:

The service suspendSelf may only be called if pre-emption is not locked, because this would create a
deadlock situation. This means that the process lock level must be equal to zero.

Associated Calls:

None.

11.4.1.6 stopThread

Purpose:

Abort the execution of another thread of the same process.

Syntax:

ReturnStatus stopThread (
in PublicId thread_id );
Description:

The service stopThread can only be used to stop threads other than the thread calling this service. It
shall place the thread identified by its thread identifier from ‘READY’ or the ‘WAITING’ state into the
‘DORMANT’ state. The service stopThread shall return ‘SUCCESS’ in this case.

If the specified thread was in the ‘DORMANT’ state already, stopThread shall return an ‘ERROR’
condition.

NATO UNCLASSIFIED 120

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

As it is applied to threads in the ‘READY’ or the ‘WAITING’ state and has immediate effect, this
service may cause the thread being stopped to leave locked objects (e.g. Semaphores, buffers, files).
It is the task of the remaining threads (especially the thread that has called stopThread) to clean up
the remaining locks.

Parameter Description:

thread_id

Data Type Definition PublicId

Description The thread identifier is a public identifier, used by an APOS client and defined in the
blueprints, enumerating the threads associated with a process. The thread shall
identify a created thread, i.e. a thread that is defined in the blueprints.

Domain Values No limitation for this service.

Prerequisite Conditions:

The referenced thread is not in status ‘DORMANT’.

Associated Calls:

- terminateSelf,

- startThread,

- deleteSemaphore,

- sendBuffer,

- unlockBuffer,

- unlockFile.

11.4.1.7 terminateSelf

Purpose:

Abort the execution of the calling thread.

Syntax:

void terminateSelf() ;
Description:

The service shall transfer the calling thread from the ‘RUNNING’ state into the ‘DORMANT’ state. If
the pre-emption is locked or the service is not completed successfully for any reason, the OS shall
raise an error. The service never returns control back to the calling thread. Therefore, any application
code after terminateSelf is unreachable.

Typically terminateSelf will be used for a controlled shutdown of a thread after having done the entire
necessary cleanup before.

Parameter Description:

There are no parameters required.

NATO UNCLASSIFIED 121

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

Pre-emption must not been locked.

All locked resources have been released.

Associated Calls:

- stopThread,

- startThread.

11.4.1.8 lockThreadPreemption

Purpose:

Disable thread rescheduling inside the local process.

Syntax:

ReturnStatus lockThreadPreemption (
out unsigned long lock_level );
Description:

This service shall exclude all other threads of the same process from scheduling and makes the
current thread the only thread inside the process that is being scheduled. The service shall further
increment the lock level of the process. The lock level indicates the number of interleafed pre-emption
locking operations. A thread may, after having locked pre-emption once, call the service again. This
will result in a lock level greater than one. A lock level greater or equal one means that no other
threads of the same process are being scheduled. This means that if lockThreadPreemption is called
more than once unlockThreadPreemption shall be called the same number of times in order to re-
enable scheduling of other threads in the same process.

This service allows a thread to prevent the normal thread rescheduling operations of the OS while
accessing critical sections or resources shared by multiple threads of the same process.

The service returns the status ‘SUCCESS’ if pre-emption could successfully be locked inside the
process. If pre-emption was not successfully locked, the service will issue an ‘ERROR’ return status
condition.

The error handler thread shall be excluded from the threads for which scheduling is inhibited by
lockThreadPreemption. If an error that occurs within a critical section causes the GSM to invoke the
error handler thread, the error handler thread shall be able to run and complete.

Parameter Description:

lock_level

Data Type Definition unsigned long

Description The number of interleafed pre-emption locking operations. Thread re-scheduling

inside a process is enabled only if the lock_level = 0. Here the value after the locking
operation is provided.

Domain Values lock_level > 0

Prerequisite Conditions:

NATO UNCLASSIFIED 122

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The lock level is initialised to zero when the process is started.

Associated Calls:

- unlockThreadPreemption.

11.4.1.9 unlockThreadPreemption

Purpose:

Recover thread rescheduling inside the local process.

Syntax:

ReturnStatus unlockThreadPreemption (
out unsigned long lock_level );
Description:

This service shall decrement the current lock level of the process. When the lock level reaches zero,
the scheduling of other threads within the same process shall be re-enabled.

For any call to the service lockThreadPreemption there shall be a corresponding call to
unlockThreadPreemption to make sure that thread pre-emption is re-enabled.

This service returns ‘SUCCESS’ when the current process lock level is greater than zero. If the lock
level is already equal to zero the service unlockThreadPreemption does not have any effect and will
return an ‘ERROR’ condition.

Parameter Description:

lock_level

Data Type Definition unsigned long

Description The number of stacked pre-emption locking operations. Thread re-scheduling inside a
process is enabled only if the lock_level = 0. Here the value after the unlocking
operation is provided.

Domain Values lock_level >= 0

Prerequisite Conditions:

None

Associated Calls:

- lockThreadPreemption.

11.4.1.10 getThreadStatus

Purpose:

Provide the current thread status.

Syntax:

NATO UNCLASSIFIED 123

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReturnStatus getThreadStatus (
in PublicId thread_id ,
out ThreadStatus thread_status ) ;
Description:

This service shall return the current status of the selected thread. If the selected thread does not exist,
an ‘ERROR’ condition shall be returned, else the return status will be ‘SUCCESS’.

This service returns the current status of the selected thread; therefore it does not influence the
scheduling of any thread.

Parameter Description:

thread_id

Data Type Definition PublicId

Description The thread identifier is a public identifier, used by an APOS client and defined in the
blueprints, enumerating the threads associated with a process. The thread shall
identify a created thread, i.e. a thread that is defined in the blueprints.

Domain Values No limitation for this service.

thread_status

Data Type Definition ThreadStatus

Description The value of the thread status for the selected thread:

Domain Values ‘DORMANT’: Any thread that is created but not started.

‘READY’: Thread is ready to be scheduled.

‘WAITING’: Thread is temporarily not scheduled.

‘RUNNING’: This is the calling thread.

Prerequisite Conditions:

The selected thread must exist.

Associated Calls:

None.

11.4.2 Time Management Services

11.4.2.1 getAbsoluteLocalTime

Purpose:

Provide the absolute local time value.

Syntax:

NATO UNCLASSIFIED 124

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReturnStatus getAbsoluteLocalTime (
out Time absolute_local_time );
Description:

This service conveys the absolute local time value as provided by the MSL at the MOS interface to
the requesting APOS client.

If the retrieval of the absolute local time value from the MSL is successful, the service shall return with
a ‘SUCCESS’ condition. If the MSL issues an error condition, getAbsoluteLocalTime shall return with
‘ERROR’ condition as well.

In order to get realistic time values, the execution time of this service shall be bounded and shall be
equal or lower to the accuracy of absolute local time.

Absolute local time is referring to a synchronised system time. Therefore, absolute local time can be
used to synchronise or time-trigger functions within a single ASAAC core system.

Parameter Description:

absolute_local_time

Data Type Definition Time

Description This value provides the absolute local time (i.e. the synchronised system time) valid
at the point of return from the service.

This time is guaranteed to be strictly monotonic.

Domain Values No special values for this service.

Prerequisite Conditions:

Absolute local time is available.

Associated Calls:

- sleepUntil,

- getRelativeLocalTime.

11.4.2.2 getAbsoluteGlobalTime

Purpose:

Provide the absolute global time value.

Syntax:

ReturnStatus getAbsoluteGlobalTime (
out Time absolute_global_time ) ;
Description:

This service conveys the absolute global time value as provided by the MSL.

NATO UNCLASSIFIED 125

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If the retrieval of the absolute global time value from MSL is successful, the service shall return with a
‘SUCCESS’ condition. If the MSL issues an error condition, getAbsoluteGlobalTime shall return with a
‘ERROR’ condition as well.

In order to get realistic time values, the execution time of this service shall be bounded and shall be
equal or lower to the accuracy of absolute global time.

Parameter Description:

absolute_global_time

Data Type Definition Time

Description This value provides the absolute global time (i.e. the synchronised time from outside
the system) valid at the point of return from the service.

This time is guaranteed to be strictly monotonously.

Domain Values No special values for this service.

Prerequisite Conditions:

Absolute global time is available.

Associated Calls:

- getRelativeLocalTime,

- getAbsoluteLocalTime.

11.4.2.3 getRelativeLocalTime

Purpose:

Provide the relative local time value.

Syntax:

ReturnStatus getRelativeLocalTime (
out Time relative_local_time );
Description:

This service conveys the relative local time value as provided by the MSL at the MOS interface to the
requesting APOS client.

Relative local time is only valid within the domain of a single module. It cannot be used for inter
process synchronisation.

If the retrieval of the relative local time value from MSL is successful, the service shall return with a
‘SUCCESS’ condition. If the MSL issues an error condition, getRelativeLocalTime shall return with
‘ERROR’ condition as well.

In order to get realistic time values, the execution time of this service shall be bounded.

Parameter Description:

NATO UNCLASSIFIED 126

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

relative_local_time

Data Type Definition Time

Description This value provides the relative local time (i.e. a high precision module local time)
valid at the point of return from the service.

This time is guaranteed to be strictly monotonously.

Domain Values No special values for this service.

Prerequisite Conditions:

Relative local time is available.

Associated Calls:

- getAbsoluteLocalTime.

11.4.3 Semaphore Synchronisation Services

11.4.3.1 createSemaphore

Purpose:

Create a counting Semaphore.

Syntax:

ResourceReturnStatus createSemaphore (
in CharacterSequence name ,
out PrivateId semaphore_id ,
in unsigned long init_value ,
in unsigned long max_value ,
in QueuingDiscipline queuing_discipline ) ;
Description:

This service shall create a counting semaphore. The semaphore shall be valid only within a single
process. A semaphore shall be identified by the ‘name’ parameter. If a semaphore is created at
multiple instances (inside a single process) all these creation operations shall provide identical
semaphore identifiers unless the semaphore has been deleted in the meantime. The OS shall provide
the semaphore identifier as a handle to be used with other semaphore services.

The service createSemaphore shall return ‘RS_SUCCESS’ if the semaphore has been created
successfully.

If the semaphore already exists, no new semaphore will be created and the service returns with a
‘RESOURCE’ condition. As createSemaphore may be called several times, maximum value and
current value shall not be affected, when createSemaphore is called for an already existing
semaphore.

The service createSemaphore shall return ‘RS_ERROR’ in one of the following cases:

- The semaphore cannot be created due to insufficient resources.

- Parameter max_value < 1

NATO UNCLASSIFIED 127

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Parameter init_value > max_value

- The OS does not provide the requested queuing_discipline.

- The requested queuing_discipline is inconsistent with a preceding creation operation.

Parameter Description:

name

Data Type Definition CharacterSequence

Description A semaphore is identified by a name. If semaphores with identical names would be

created several times from different contexts within the same process, all semaphore
identifiers would refer to the same semaphore object.

Domain Values There is an OS determined length limitation for a CharacterSequence.

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier is assigned by the OS. It is providing a handle for accessing
a semaphore object, once it has been identified by its name at the creation of the
semaphore.

Domain Values The value of this private id is left completely to the discretion of the OS.

init_value

Data Type Definition unsigned long

Description The initial value is the semaphores’ starting value after creation. It is indicating the
number of free resources at the time the semaphore is created.

Domain Values max_value  init_value

As the semaphore’s counter value reflects the number of free resources and the
maximum value their total number, the init value shall not exceed the maximum
value.

max_value

Data Type Definition unsigned long

Description The maximum value parameter is the maximum value that the semaphore can be
signalled to. It reflects the number of resources available.

Domain Values max_value  1

queuing_discipline

Data Type Definition QueuingDiscipline

Description This parameter mandates a particular thread queuing policy to be associated with a
semaphore. This queuing policy applies whenever multiple threads get blocked

NATO UNCLASSIFIED 128

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

waiting for a semaphore.

the availability of queuing disciplines is dependent on the OS implementation. For

instance if the OS would not provide priority based scheduling, priority queuing did
not make sense.

Domain Values QUEUING_DISCIPLINE_FIFO

The threads shall be queued in FIFO order. This means, the first thread that has been
queued shall be the first to be released, when a semaphore gets posted.

QUEUING_DISCIPLINE_PRIORITY

Threads shall be queued ordered by their scheduling priority. This means that the
waiting thread that has the highest priority shall be the first one to be released.
Threads with identical priority shall be queued in FIFO order.

Prerequisite Conditions:

None.

Associated Calls:

- deleteSemaphore.

11.4.3.2 deleteSemaphore

Purpose:

Delete a semaphore.

Syntax:

ReturnStatus deleteSemaphore (
in PrivateId semaphore_id );
Description:

The semaphore addressed by its semaphore identifier shall be deleted. Deletion means, that neither
the semaphore’s name nor its identifier refers to a semaphore object any more. Deletion of a
semaphore can only happen if no threads are blocked waiting at the semaphore. Therefore, the
deletion of a semaphore shall not impact the status of any thread.

The service deleteSemaphore shall return a ‘SUCCESS’ condition when the semaphore is
successfully deleted. It shall return an ‘ERROR’ condition if the semaphore cannot be deleted due to
waiting threads or if the semaphore does not exist

Parameter Description:

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier is providing a handle for accessing a semaphore object.

Domain Values The value of this private id is left completely to the discretion of the OS.

Prerequisite Conditions:

NATO UNCLASSIFIED 129

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

There shall be no threads currently waiting for the semaphore.

Associated Calls:

- createSemaphore.

11.4.3.3 waitForSemaphore

Purpose:

Wait at semaphore until semaphore is available.

Syntax:

TimedReturnStatus waitForSemaphore (
in PrivateId semaphore_id ,
in TimeInterval timeout );
Description:

This service shall try to get access by the semaphore identified.

If the current value of the specified semaphore is positive the service shall decrement the
semaphore’s current value and continue execution regardless of the value of the timeout parameter.
The service shall return a ‘TM_SUCCESS’ condition in this case.

If the semaphore’s current value is zero and the specified timeout is not zero, the current thread shall
be transferred from the ‘RUNNING’ state to the ‘WAITING’ state. The thread shall wait at the
semaphore until either the semaphore becomes available or the specified timeout expires. If the
semaphore becomes available and the current thread is the next one to be selected in accordance
with the queuing policy, the service shall decrement the semaphore’s current value, transfer the
waiting thread into the ‘READY’ state and return with a ‘TM_SUCCESS’ condition. If the timeout
expires, the semaphore’s current value shall be left unchanged, the waiting thread shall be transferred
into the ‘READY’ state and the service shall return with a ‘TM_TIMEOUT’ condition.

If the semaphore’s current value is zero and the specified timeout is zero, the service shall not block
the calling thread. The thread shall continue execution the semaphore’s current value unchanged.
The service shall return a ‘TM_TIMEOUT’ condition in this case.

This service does only work if the identified semaphore exists. If the semaphore does not exist the
service shall return with a ‘TM_ERROR’ condition.

If the current process lock level is greater than 0 then the call shall terminate and return TM_ERROR.

Parameter Description:

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier provides a handle for accessing a semaphore object.

Domain Values The value of this private id is left completely to the discretion of the OS.

timeout

Data Type Definition TimeInterval

NATO UNCLASSIFIED 130

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The timeout parameter defines the maximum time a thread shall wait for passing a
semaphore.

Domain Values TimeInterval: zero

This specifies a non-blocking condition. The semaphore is passed if it is available. If it

is not, the service nevertheless returns immediately.

TimeInterval: infinite

This specifies an unbounded waiting for a semaphore.

Prerequisite Conditions:

The current process lock level is zero (pre-emption is enabled).

Associated Calls:

- postSemaphore.

11.4.3.4 postSemaphore

Purpose:

Indicate semaphore availability.

Syntax:

ReturnStatus postSemaphore (
in PrivateId semaphore_id );
Description:

This service shall increment the semaphore’s current value up to the maximum value of the
semaphore. If the current value of the semaphore was lower than the maximum value, the service
shall return with a ‘SUCCESS’ condition. If the current value of the semaphore was already the
maximum value, the service shall return an ‘ERROR’ condition without modifying the semaphore’s
current value. The call returns ERROR if the semaphore does not exist.

If there are threads waiting to pass the semaphore, the first thread according to the queuing policy
shall decrement the semaphore’s current value again and shall be transferred from the ‘WAITING’
state to the ‘READY’ state.

Parameter Description:

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier provides a handle for accessing a semaphore object.

Domain Values The value of this private id is left completely to the discretion of the OS.

Prerequisite Conditions:

The semaphore’s current value must be lower than the semaphore’s maximum value.

NATO UNCLASSIFIED 131

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- waitForSemaphore.

11.4.3.5 getSemaphoreStatus

Purpose:

Provide the current value and the number of waiting threads for a semaphore.

Syntax:

ReturnStatus getSemaphoreStatus (
in PrivateId semaphore_id ,
out unsigned long current_value ,
out unsigned long waiting_callers ) ;
Description:

This service shall return the current value of the semaphore. If the current value is zero, this means
that the semaphore is blocked and there may be waiting callers. The service therefore also provides
the number of waiting callers, specifying the number of threads waiting to pass at a blocked
semaphore.

This service shall execute successfully, returning a ‘SUCCESS’ condition, if the semaphore
addressed by its semaphore identifier exists. The service shall return with an ‘ERROR’ condition if the
semaphore does not exist.

Parameter Description:

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier provides a handle for accessing a semaphore object.

Domain Values The value of this private id is left completely to the discretion of the OS.

current_value

Data Type Definition unsigned long

Description The current value of the semaphore indicates the number of free resources. A value
of zero means that the semaphore is blocked.

Domain Values 0  current_value  max_value

waiting_callers

Data Type Definition unsigned long

Description This is the number of threads waiting to pass a blocked semaphore.

Domain Values waiting_callers = 0 if current_value > 0.

waiting_callers  0 if current_value = 0.

NATO UNCLASSIFIED 132

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

None.

Associated Calls:

None.

11.4.3.6 getSemaphoreId

Purpose:

Provide the semaphore id associated with the given semaphore name.

Syntax:

ReturnStatus getSemaphoreId (
in CharacterSequence name ,
out PrivateId semaphore_id );
Description:

This service shall return the id of the semaphore addressed by its name.

This service shall complete with a ‘SUCCESS’ condition if the semaphore addressed by its name
exists. It shall return an ‘ERROR’ status if it does not exist.

Parameter Description:

name

Data Type Definition CharacterSequence

Description A semaphore is identified by a name. If semaphores with identical names would be

created several times from different contexts within the same process, all semaphore
identifiers would refer to the same semaphore object.

Domain Values There is an OS determined length limitation for a CharacterSequence.

semaphore_id

Data Type Definition PrivateId

Description The semaphore identifier associated with the given name.

Domain Values NIL

if the semaphore does not exist.

Prerequisite Conditions:

None.

Associated Calls:

- createSemaphore.

NATO UNCLASSIFIED 133

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.4.4 Event Synchronisation Services

11.4.4.1 createEvent

Purpose:

Create a named event and associate it with an event identifier.

Syntax:

ResourceReturnStatus createEvent (
in CharacterSequence name ,
out PrivateId event_id );
Description:

This service shall create a named event and associate it with an event identifier. The visibility scope
of the event is limited to one process. Upon creation the event is set to the ‘RESET’ state.

If this service is called with the name of an event that has already been created, it shall provide the
event identifier that is associated with that event. In this case the state of the event shall not be
affected.

The service shall return a ‘RS_SUCCESS’ condition if the event was created successfully. It shall
return a ‘RS_ERROR’ condition if the event could not be generated due to insufficient resources.

If the event exists already, no new event will be created and the service returns with a
‘RS_RESOURCE’ condition.

Parameter Description:

name

Data Type Definition CharacterSequence

Description An event is identified by a name. If events with identical names are created several
times from different contexts within the same process, all event identifiers will refer to
the same event object.

Domain Values There is an OS determined length limitation for a CharacterSequence.

event_id

Data Type Definition PrivateId

Description The event identifier is assigned by the OS. It provides a handle for accessing an
event object, once it has been identified by its name at the creation of the event.

Domain Values The value of this private id is left completely to the discretion of the OS.

Prerequisite Conditions:

None.

Associated Calls:

- deleteEvent.

NATO UNCLASSIFIED 134

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.4.4.2 deleteEvent

Purpose:

Delete an event object.

Syntax:

ReturnStatus deleteEvent (
in PrivateId event_id );
Description:

The event addressed by its event identifier shall be deleted. This means neither that neither the
event’s name nor its identifier now refer to an event object. Deletion of an event can only happen if no
threads are being blocked, waiting for an event to occur. This means that the deletion of an event is
conserving the current status of the process thread ensemble; therefore it does not have any impact
on pre-emption.

The service deleteEvent shall return a ‘SUCCESS’ condition when the event is successfully deleted or
if the event does not exist; it shall return an ‘ERROR’ condition if the event cannot be deleted due to
waiting threads.

Parameter Description:

event_id

Data Type Definition PrivateId

Description This parameter identifies the event to be deleted. After deletion it does not address a
valid event object any more.

Domain Values No special conditions for this parameter.

Prerequisite Conditions:

There shall be no threads currently waiting for the event to occur.

Associated Calls:

- createEvent.

11.4.4.3 setEvent

Purpose:

Set event state to ‘SET’.

Syntax:

ReturnStatus setEvent (
in PrivateId event_id ) ;
Description:

This service shall set the specified event to the ‘SET’ state regardless of its previous state. If the
event exists the service shall return ‘SUCCESS’ when the event is in the ‘SET’ state.

NATO UNCLASSIFIED 135

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If the state of the event was ‘RESET’ before, there may be threads were waiting on that event to
occur. Every thread that is waiting for the event shall be transferred from the ‘WAITING’ state to the
‘READY’ state.

The service shall return an ‘ERROR’ condition if the event does not exist.

Parameter Description:

event_id

Data Type Definition PrivateId

Description This parameter identifies the event to be set.

Domain Values The event identifier shall be associated with an existing event object.

Prerequisite Conditions:

None

Associated Calls:

- resetEvent.

11.4.4.4 resetEvent

Purpose:

Set event state to ‘RESET’.

Syntax:

ReturnStatus setEvent (
in PrivateId event_id ) ;
Description:

This service shall set the specified event to the ‘RESET’ state regardless of its previous state. If the
event exists the service shall return ‘SUCCESS’ when the event is in ‘RESET’ state.

The service shall return an ‘ERROR’ condition if the event does not exist.

Parameter Description:

event_id

Data Type Definition PrivateId

Description This parameter identifies the event to be reset.

Domain Values The event identifier shall be associated with an existing event object.

Prerequisite Conditions:

None.

Associated Calls:

NATO UNCLASSIFIED 136

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- setEvent.

11.4.4.5 waitForEvent

Purpose:

Wait for event to be in the ‘SET’ state.

Syntax:

TimedReturnStatus waitForEvent (
in PrivateId event_id ,
in TimeInterval timeout ) ;
Description:

This service shall block its calling thread until the specified event is in state ‘SET’. If the event is
already in state ‘SET’ execution of the calling thread shall be continued immediately.

If the event is in state ‘RESET’ when the service is called and the timeout period specified is not zero,
the calling thread shall be transferred into the ‘WAITING’ state. It shall remain in the ‘WAITING’ state
until the event state is ‘SET’. If the event state is ‘SET’ when returning the service shall return with a
‘TM_SUCCESS’ condition. If the timeout period expires before the event is transferred to state ‘SET’,
the service shall return with a ‘TM_TIMEOUT’ condition.

If the event is in state ‘RESET’ when the service is called and the timeout period specified is zero,
execution of the calling thread shall be continued immediately. The service shall return a
‘TM_TIMEOUT’ condition in this case.

The service shall return with a ‘TM_ERROR’ condition if the event does not exist.

If the process lock level is greater than 0 then the call shall terminate and return TM_ERROR.

Parameter Description:

event_id

Data Type Definition PrivateId

Description This parameter identifies the event to wait for.

Domain Values The event_id shall refer to an existing event object.

timeout

Data Type Definition TimeInterval

Description The timeout parameter specifies the maximum time the calling thread shall be
blocked waiting for the event to occur.

NATO UNCLASSIFIED 137

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values Timeout: zero

The service waitForEvent returns immediately with a ‘SUCCESS’ condition if the

event was set or with a ‘TIMEOUT’ condition if the event was reset.

Timeout: infinite

The thread will wait for an unbounded period of time for the event to occur.

Prerequisite Conditions:

The current lock level of the process shall be zero, i.e. pre-emption is enabled.

Associated Calls:

- setEvent.

11.4.4.6 getEventStatus

Purpose:

Provide the current state of the event and the number of waiting callers.

Syntax:

ReturnStatus getEventStatus (
in PrivateId event_id ,
out EventStatus event_status ,
out unsigned long waiting_callers ) ;
Description:

This service shall return the current status of the event object. If the current event status is ‘RESET’,
this means that there may be waiting callers. The service therefore also provides the number of
waiting callers specifying the number of threads waiting for the event condition to be set.

This service shall execute successfully returning a ‘SUCCESS condition if the event addressed by its
event identifier exists. The service shall return with an ‘ERROR’ condition if the event does not exist.

Parameter Description:

event_id

Data Type Definition PrivateId

Description This parameter identifies the event for which the status shall be provided.

Domain Values The parameter shall refer to an existing event object.

event_status

Data Type Definition EventStatus

Description This parameter provides the current event state of the specified event.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 138

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

waiting_callers

Data Type Definition unsigned long

Description This parameter provides the number of threads currently waiting for the event to
occur.

Domain Values The number of waiting callers shall be zero if the event status is ‘SET’.

Prerequisite Conditions:

None.

Associated Calls:

None.

11.4.4.7 getEventId

Purpose:

Provide the event identifier that is associated with named event.

Syntax:

ReturnStatus getEventId (
in CharacterSequence name ,
out PrivateId event_id ) ;
Description:

This service shall return the id of the event addressed by its name.

This service shall complete with a ‘SUCCESS’ condition if the event addressed by its name exists. It
shall return an ‘ERROR’ status if it does not exist.

Parameter Description:

name

Data Type Definition CharacterSequence

Description The name of an event.

Domain Values There is an OS determined length limitation for a CharacterSequence.

event_id

Data Type Definition PrivateId

Description The event identifier that is associated with a named event object if the event exists.

Domain Values NIL

If the event does not exist.

NATO UNCLASSIFIED 139

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

None.

Associated Calls:

None.

11.4.5 Error Handling Services

11.4.5.1 logMessage

Purpose:

This service allows the current thread to write a message through the OSL.

Syntax:

ReturnStatus logMessage (
in CharacterSequence log_message ,
in LogMessageType message_type );
Description:

This service is used if the application detects erroneous behaviour, in the case of fault logging, or for
system logging. The parameter message_type identifies the type of message that is being written.
This service returns SUCCESS if the message is successfully written to the OSL.

Parameter Description:

log_message

Data Type Definition CharacterSequence

Description The sequence of characters to be written.

Domain Values No special values are associated with this parameter.

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None.

Associated Calls:

- getLogReport,

- writeLog.

NATO UNCLASSIFIED 140

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.4.5.2 raiseApplicationError

Purpose:

Signal an Application Error to the OS.

Syntax:

ReturnStatus raiseApplicationError (
in ErrorCode error_code ,
in CharacterSequence error_message ) ;
Description:

The OS conveys this error to the GSM via the SMOS service getError. As a result, based on blueprint
information, the error handler may be invoked to take the recovery action for the thread, which raised
the error code.

When the service is completed successfully it returns SUCCESS, otherwise it returns ERROR.

Parameter Description:

error_code

Data Type Definition ErrorCode

Description The Code corresponding to the Error that has been raised

Domain Values Refer to ErrorCode domain values

error_message

Data Type Definition CharacterSequence

Description The Message corresponding to the Error that has been raised

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- getErrorInformation,

- activateErrorHandler.

11.4.5.3 getErrorInformation

Purpose:

Retrieve information on the error that is the cause of the activation of the error handler

Syntax:

ReturnStatus getErrorInformation (

NATO UNCLASSIFIED 141

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

out PublicId faulty_thread_id ,

out ErrorType error_type ,
out ErrorCode error_code ,
out CharacterSequence error_message );
Description:

The Error Handler retrieves information represented by the parameters faulty_thread_id,

error_type, error_code and error_message. A previous activateErrorHandler has provided
this information to the OS.

When the service is completed successfully, it returns SUCCESS.

When the calling thread is not the Error Handler, it returns ERROR.

When no error information is available, it returns ERROR.

Parameter Description:

faulty_thread_id

Data Type Definition PublicId

Description This Id identifies the thread that has raised the Error

Domain Values 0..232-1

error_type

Data Type Definition ErrorType

Description The kind of Error that shall be handled.

Domain Values Refer to ErrorType domain values

error_code

Data Type Definition ErrorCode

Description The Code corresponding to the Error that has been raised

Domain Values Refer to ErrorCode domain values

error_message

Data Type Definition CharacterSequence

Description The Message corresponding to the Error that has been raised

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The service activateErrorHandler of the SMOS interface has requested the OS starting the Error
Handler. The OS has set up the input parameters of getErrorInformation.

Associated Calls:

NATO UNCLASSIFIED 142

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- raiseApplicationError,

- activateErrorHandler.

11.4.5.4 terminateErrorHandler

Purpose:

Terminate the error handler thread with a return status.

Syntax:

void terminateErrorHandler (
in ReturnStatus return_status ) ;
Description:

As the GSM is using the blocking service activateErrorHandler, it requires the information whether the
application error handler has run successfully or not. Therefore, this special service shall be used by
the error handler thread and shall not be used by any other thread.

It shall terminate the error handler thread and transfer it into state DORMANT. The return status
parameter shall be passed back to the GSM and provided with the activateErrorHandler service
results.

Parameter Description:

return_status

Data Type Definition ReturnStatus

Description The error handler can only have two results, either SUCCESS or ERROR.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The service activateErrorHandler of the SMOS interface has requested the OS starting the Error
Handler. The application error handler thread has started.

Associated Calls:

- activateErrorHandler.

11.4.6 Debugging Services

This section defines debugging services, which are used for development, only.

11.4.6.1 getDebugErrorInformation

Purpose:

This service retrieves error information of the latest that has occurred in the context of the calling
thread.

Syntax:

NATO UNCLASSIFIED 143

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReturnStatus getDebugErrorInformation (
out ErrorType error_type ,
out ErrorCode error_code ,
out CharacterSequence error_message );
Description:

The primary effect of any error occurring when any APOS service is being called is that the value
returned by the service is ‘ERROR’. Additionally, more detailed error information is provided to the
GSM at the SMOS interface. In order to make the same information available to the application itself
for debugging purposes, the OS shall store the error code and error message associated with the
latest error that has occurred in the context of the calling thread (please note that a thread context
always implies a particular process context). The service ‘getDebugErrorInformation ‘ makes this
information available to the Application Process. Calling the service once shall destroy the error
information stored. If error information is available the service shall return the value ‘SUCCESS’.

There is no interference with pre-emption, as the information is stored within the context of the calling
thread. The service is non-blocking. In case it is called without any error information being available,
the service shall return ‘ERROR’. This error is an exception of the rule that all errors occurring on
APOS service calls are notified to GSM. Therefore, the service ‘getDebugErrorInformation‘ shall in
case of failure not produce any error information and shall not forward any error information to the
GSM.

In case error information is not read until another error occurs in the same thread context, the new
value shall overwrite the error information.

The service may also be used in GSM context. In this case it will provide information about the latest
error that has occurred from calling APOS, SMOS or SMBP services.

Parameter Description:

error_type

Data Type Definition ErrorType

Description The error type provides an identifier that specifies the kind of error that has occurred.

Domain Values APPLICATION_ERROR, APOS_CLIENT_ERROR, SMOS_ERROR, SMBP_ERROR

error_code

Data Type Definition ErrorCode

Description The error code provides an identifier that provides specific information about the
nature of the error, which has been occurred. The value of the identifier is defined by
the service.

Domain Values No special values are associated with this parameter.

error_message

Data Type Definition CharacterSequence

Description Additional information or verbal description for the error providing information on the
latest error, which has occurred.

Domain Values A bounded string of 256 characters maximum length.

NATO UNCLASSIFIED 144

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

None

Associated Calls:

None

11.4.7 Communication Services

11.4.7.1 sendMessageNonblocking

Purpose:

Copy a message into a buffer to be sent on a VC.

Syntax:

ResourceReturnStatus sendMessageNonblocking (
in PublicId local_vc_id ,
in Address message_buffer_reference ,
in unsigned long actual_size );
Description:

This service shall initiate the sending of a message through a VC that is attached to the local VC
identifier local_vc_id. The buffer data is described in terms of actual length and location by the
parameter actual_size and location by the parameter message_buffer_reference. The OS shall copy
the message data from the buffer in the caller memory to a buffer into the OS memory that is
associated with a VC for sending direction. The OS also controls the further transfer of the buffer data
through the associated VC. The service returns immediately and independently from the actual
sending of the data, after the message buffer has been written.

The service shall return ‘RS_SUCCESS’ on successful completion.

The service shall return ‘RS_ERROR’ when:

- No VC for sending direction is attached for the given value of parameter local_vc_id,

- The actual length of data to be sent exceeds the OS buffer length that is defined in the blueprints.

The service shall return ‘RS_RESOURCE’ when:

- Sufficient buffer space is not available.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 145

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference specifies the location of the buffer, which
holds the message data to be sent.

Domain Values Provided by caller.

actual_size

Data Type Definition unsigned long

Description This parameter specifies the actual length in bytes of the message data that shall be
transferred.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for sending direction.

Buffer resources are available. Buffer resources are assigned to a process local instance of a VC by
means of the attachment of a VC to a process and a thread. This attachment operation defines the
amount of buffer resources available.

Associated Calls:

- receiveMessageNonblocking.

11.4.7.2 receiveMessageNonblocking

Purpose:

Read message data from a buffer received from a VC

Syntax:

ResourceReturnStatus receiveMessageNonblocking (
in PublicId local_vc_id ,
in unsigned long maximum_size ,
in Address message_buffer_reference ,
out unsigned long actual_size );
Description:

The service shall read the next available message buffer that is associated with the VC identifier
provided by the parameter local_vc_id. If a message is available the operating system copies the
message data from operating system memory into the buffer in the caller memory. This is specified in
terms of location and maximum size by the parameters message_buffer_reference and
maximum_size respectively. The OS further provides the actual size of the message buffer with the
parameter actual_size.

If no message buffer is available the service returns immediately.

The service shall return ‘RS_SUCCESS’ on successful completion. In this case the OS message
buffer is released.

NATO UNCLASSIFIED 146

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The service shall return ‘RS_RESOURCE’ when:

- There is no buffered message is available at the time the service is called.

The service shall return ‘RS_ERROR’ when:

- No VC for receiving direction is attached for the given value of parameter local_vc_id,

- The actual message size exceeds the size given by the parameter maximum_size.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

maximum_size

Data Type Definition unsigned long

Description This parameter specifies the maximum size in bytes that the message received may
have due to the caller’s resources provided to get message data from OS.

Domain Values No special values are associated with this parameter.

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference specifies the location of a buffer where the
received message shall be written.

Domain Values Provided by caller

actual_size

Data Type Definition unsigned long

Description This parameter provides the actual size in bytes of the message data being provided
by the OS.

Domain Values If return status is ‘SUCCESS’: No special values are associated.

If return status is not ‘SUCCESS’: actual_size = 0.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

VC message data have been received through the VC, which is attached to the local VC identifier
local_vc_id.

NATO UNCLASSIFIED 147

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- sendMessageNonblocking,

- receiveMessage,

- receiveBuffer.

11.4.7.3 sendMessage

Purpose:

Send message through a VC.

Syntax:

TimedReturnStatus sendMessage (
in PublicId local_vc_id ,
in TimeInterval timeout ,
in Address message_buffer_reference ,
in unsigned long actual_size );
Description:

This service shall initiate the sending of a message through a VC that is attached to the local VC
identifier local_vc_id. The buffer data is described in terms of actual length and location by the
parameters actual_size and message_buffer_reference. The operating system shall copy the
message data from the buffer in the caller memory to a buffer in the operating system memory that is
associated with a VC for the transmission direction. The operating system also controls the
subsequent transfer of the buffer data through the associated VC. The service returns immediately
and independently from the actual sending of the data, after the message buffer has been written.

If sufficient OS buffer space is not immediately available, the calling thread is transferred into
‘WAITING’ state. The calling thread will be transferred to ‘READY’ state either when a buffer has
become available for writing or if waiting time exceeds the period specified by the timeout parameter.

The service shall return ‘TM_SUCCESS’ on successful completion.

The service shall return ‘TM_TIMEOUT’ when sufficient buffer space is not available within timeout.

The service shall return ‘TM_ERROR’ when:

- No VC for sending direction is attached for the given value of parameter local_vc_id,

- The actual length of data to be sent exceeds the OS buffer length that is defined in the blueprints.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 148

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

timeout

Data Type Definition TimeInterval

Description The parameter timeout specifies the maximum waiting time between the time the
service is called and the time writing of the buffer is completed.

In case of an infinite timeout period the service shall never return, unless a sending
buffer associated with the VC.

In case of a zero timeout the behaviour of sendMessage shall be identical to the

behaviour of the service sendMessageNonblocking.

Domain Values timeout ≥ 0 or timeout = ‘infinite’

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference specifies the location of the buffer, which
holds the message data to be sent.

Domain Values limited to caller memory

actual_size

Data Type Definition unsigned long

Description This parameter specifies the actual length in bytes of the message data that shall be
transferred.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for the sending direction.

Buffer resources are available. Buffer resources are assigned to a process local instance of a VC by
means of the attachment of a VC to a process and a thread. This attachment operation defines the
amount of buffer resources available.

Associated Calls:

- receiveMessage,

- sendMessageNonblocking ,

- sendBuffer.

11.4.7.4 receiveMessage

Purpose:

Receive message from a VC.

Syntax:

NATO UNCLASSIFIED 149

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

TimedReturnStatus receiveMessage (
in PublicId local_vc_id ,
in TimeInterval timeout ,
in unsigned long maximum_size ,
in Address message_buffer_reference ,
out unsigned long actual_size );
Description:

The service shall read the next available message buffer that is associated with the VC identifier
provided by the parameter local_vc_id. If a message is available the OS shall copy the message data
from OS memory into the buffer in the caller memory, which is specified in terms of location and
maximum size by the parameters message_buffer_reference, respectively maximum_size. The OS
further provides the actual size of the message buffer with the parameter actual_size.

If a message data buffer is not immediately available, the calling thread is transferred into ‘WAITING’
state. The calling thread will be transferred to ‘READY’ state either when a message buffer has
become available or if waiting time exceeds the period specified by the timeout parameter.

The service shall return ‘TM_SUCCESS’ on successful completion. In this case the OS message
buffer is released.

The service shall return ‘TM_TIMEOUT’ when a message buffer is not available within the timeout
period.

The service shall return ‘TM_ERROR’ when:

- No VC for receiving direction is attached for the given value of parameter local_vc_id,

- The actual message size exceeds the size given by the parameter maximum_size.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The parameter timeout specifies the maximum waiting time between the time the
service is called and the time a message is received through the VC that is
addressed by local_vc_id.

In case of an infinite timeout period the service shall never return, unless a message
is received through the VC.

In case of a zero timeout the behaviour of receiveMessage shall be identical to the

behaviour of the service receiveMessageNonblocking.

Domain Values timeout ≥ 0 or timeout = ‘infinite’

NATO UNCLASSIFIED 150

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

maximum_size

Data Type Definition unsigned long

Description This parameter specifies the maximum size in bytes that the message received may
have due to the caller’s resources provided to get message data from OS.

Domain Values No special values are associated with this parameter.

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference specifies the location of a buffer where the
received message shall be written.

Domain Values Provided by caller

actual_size

Data Type Definition unsigned long

Description This parameter provides the actual size in bytes of the message data being provided
by the OS.

Domain Values If return status is ‘SUCCESS’: No special values are associated.

If return status is not ‘SUCCESS’: actual_size = 0.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

VC message data have been received through the VC, which is attached to the local VC identifier
local_vc_id.

Associated Calls:

- sendMessage,

- receiveMessageNonblocking,

- receiveBuffer.

11.4.7.5 lockBuffer

Purpose:

Get hold of a VC message buffer.

Syntax:

TimedReturnStatus lockBuffer (
in PublicId local_vc_id ,
in TimeInterval timeout ,

NATO UNCLASSIFIED 151

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

out Address message_buffer_reference ,

in unsigned long maximum_size );
Description:

This service shall lock a message buffer that is associated with the VC, which is specified by the
parameter local_vc_id in order to provide message data into this buffer for sending. The buffer data is
described in terms of its maximum size needs by the parameter maximum_size and location by the
parameter message_buffer_reference. The OS shall lock a buffer of sufficient size.

If a buffer is not immediately available, the calling thread is transferred into ‘WAITING’ state. It will be
passed on to ‘READY’ state, either when a message buffer has become available or when waiting
time exceeds the period specified by the timeout parameter.

The service shall return ‘TM_SUCCESS’ on successful completion.

The service shall return ‘TM_TIMEOUT’ when:

- Sufficient buffer space is not available by expiration time of the period specified by the timeout
parameter.

The service shall return ‘TM_ERROR’ when:

- No VC for sending direction is attached for the given value of parameter local_vc_id,

- The actual length of data to be sent exceeds the OS buffer length that is defined in the blueprints.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The parameter timeout specifies the maximum waiting time between the time the
service is called and the time a buffer associated with the VC that is addressed by
local_vc_id, is available.

In case of an infinite timeout period the service shall never return, unless a buffer
becomes available.

Domain Values timeout ≥ 0 or timeout = ‘infinite’

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference provides the location of the locked buffer.

NATO UNCLASSIFIED 152

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values Provided by OS.

maximum_size

Data Type Definition unsigned long

Description This parameter specifies the upper boundary of the buffer size requirements of the
caller.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

Buffer resources are available. Buffer resources are assigned to a process local instance of a VC by
means of the attachment of a VC to a process and a thread. This attachment operation defines the
amount of buffer resources available.

Associated Calls:

- sendBuffer,

- unlockBuffer.

11.4.7.6 sendBuffer

Purpose:

Send a buffered message through a VC and unlock the buffer.

Syntax:

ReturnStatus sendBuffer (
in PublicId local_vc_id ,
in Address message_buffer_reference ,
in unsigned long actual_size );
Description:

This service shall initiate the message passed with the parameter message_buffer_reference to be
sent through the VC that is addressed by the parameter local_vc_id. The size of the message to be
transferred is specified by the parameter actual_size. The actual sending operation is under the
control of the OS and may be deferred. The buffer that is provided with the parameter
message_buffer_reference shall have been locked before by service lockBuffer. After transmitting the
buffer data through the VC, the OS shall unlock the buffer.

The service shall return ‘SUCCESS’ on successful completion.

The service shall return ‘ERROR’ when:

- No VC for sending direction is attached for the given parameter local_vc_id,

- The provided buffer is not a locked buffer,

- The actual length of the buffer exceeds the maximum length of the buffer.

Parameter Description:

NATO UNCLASSIFIED 153

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the
scope of the process. An actual VC may be attached to that VC identifier,
defining a 1:1 mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference specifies the location of a locked

message buffer, which holds the message data to be sent.

Domain Values Provided by OS.

actual_size

Data Type Definition unsigned long

Description This parameter specifies the actual length in bytes of the message data that
shall be transferred.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

The buffer provided shall be identical to a buffer that has been locked before.

Associated Calls:

- lockBuffer,

- sendMessage,

- sendMessageNonblocking.

11.4.7.7 receiveBuffer

Purpose:

Provide a buffer with message data received from a VC.

Syntax:

TimedReturnStatus receiveBuffer (
in PublicId local_vc_id ,
in TimeInterval timeout ,
out Address message_buffer_reference ,
out unsigned long actual_size );
Description:

NATO UNCLASSIFIED 154

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The service shall provide the next available message buffer that is associated with the VC identifier
provided by the parameter local_vc_id. The buffer shall be provided to the caller as parameter
message_buffer_reference. The OS shall provide the actual size of the message buffer with the
parameter actual_size. After completion of message processing it is up to the caller to unlock the
buffer.

If a buffer, which is filled with message data, is not immediately available, the calling thread is
transferred into ‘WAITING’ state. The calling thread will be passed on to ‘READY’ state, either when a
message buffer has become available, or when waiting time exceeds the period specified by the
timeout parameter.

The service shall return ‘TM_SUCCESS’ on successful completion.

The service shall return ‘TM_TIMEOUT’ when:

- After expiration of the period specified by the timeout parameter no filled message buffer is
available.

The service shall return ‘TM_ERROR’ when

- No VC for receiving direction is attached for the given value of parameter local_vc_id.

Parameter Description:

local_vc_id

Data Type Definition PublicId

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The parameter timeout specifies the maximum waiting time between the time the
service is called and the time a buffer associated with the VC that is addressed by
local_vc_id, is available with data received on that VC.

In case of an infinite timeout period the service shall never return, unless a message
is received.

Domain Values timeout ≥ 0 or timeout = ‘infinite’

message_buffer_reference

Data Type Definition Address

Description The parameter message_buffer_reference provides the location of a locked buffer

containing received message data.

Domain Values Provided by caller

actual_size

NATO UNCLASSIFIED 155

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition unsigned long

Description This parameter provides the actual message size in bytes being provided by the OS
within the returned message buffer.

Domain Values If return status is ‘SUCCESS’: No special values are associated.

If return status is not ‘SUCCESS’: actual_size = 0.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

Sufficient buffer space shall be available in order to receive the messages on the attached VC.

Associated Calls:

- unlockBuffer,

- receiveMessage,

- receiveMessageNonblocking.

11.4.7.8 unlockBuffer

Purpose:

Release a VC message buffer

Syntax:

ReturnStatus unlockBuffer (
in PublicId local_vc_id ,
in Address message_buffer_reference );
Description:

This service shall unlock a message buffer associated with the VC that is addressed by the parameter
local_vc_id. The buffer is passed back to the control of the OS resource management and is no
longer available to the caller. The parameter message_buffer_reference specifies the buffer, which is
released by the caller.

The service shall return ‘SUCCESS’ on successful completion.

The service shall return ‘ERROR’ when:

- No VC is attached for the given value of parameter local_vc_id,

- The provided buffer is not a locked buffer.

Parameter Description:

local_vc_id

Data Type Definition PublicId

NATO UNCLASSIFIED 156

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description This identifier specifies a process local VC identifier that is valid within the scope of
the process. An actual VC may be attached to that VC identifier, defining a 1:1
mapping of the process local VC identifier to the VC.

Domain Values No special values are associated with this parameter.

message_buffer_reference

Data Type Definition Message

Description The parameter message_buffer_reference specifies a locked buffer.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A VC is attached to the local VC Id. This VC shall be defined for receiving direction.

The buffer provided shall be identical to a buffer that has been locked before.

Associated Calls:

- receiveBuffer,

- lockBuffer.

11.4.7.9 waitOnMultiChannel

Purpose:

Wait for one or all out of a set of VC’s have been received.

Syntax:

TimedReturnStatus waitOnMultiChannel (
in PublicIdSet vc_set_in ,
in unsigned long min_no_vc ,
out PublicIdSet vc_set_out ,
in TimeInterval timeout );
Description:

This service waits for a set of VC’s that is specified by a set VC identifiers specified by parameter
vc_set_in until for a minimum number of these VC’s messages have been received and are buffered.
The set of VC’s, which actually have received data, is provided in the parameter vc_set_out. For
getting hold of the message data, the services receiveMessage, receiveMessageNonblocking or
receiveBuffer can be used. The parameter min_no_vc defines the minimal number of VC’s that shall
have been received for the transfer to return successfully.

If a sufficient number of VC message buffers are not immediately available, the calling thread is
transferred into ‘WAITING’ state. The calling thread will be passed on to ‘READY’ state, either when a
message buffer has become available, or when waiting time exceeds the period specified by the
timeout parameter.

The service shall return ‘TM_SUCCESS’ on successful completion.

The service shall return ‘TM_TIMEOUT’ when:

NATO UNCLASSIFIED 157

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- After expiration of the period specified by the timeout parameter a sufficient number of VC
message buffers is not available.

The service shall return ‘TM_ERROR’ when:

- Any VC identifier included in the vc_set_in parameter is not attached to a receiving VC,

- The value of min_no_vc exceeds the number of VC identifiers given by vc_set_in,

- Duplicate VC identifiers are contained in vc_set_in.

Parameter Description:

vc_set_in

Data Type Definition PublicIdSet

Description Specifies a set containing local VC identifiers, which are expected to be received.

Domain Values Only receiving VC

min_no_vc

Data Type Definition unsigned long

Description Specifies the minimum number of VC’s, which have to receive a message in order to
complete the service.

Domain Values min_no_vc > 0

vc_set_out

Data Type Definition PublicIdSet

Description Provides a set containing the local VC identifiers, for which a filled message buffer is
available.

Domain Values A subset of vc_set_in

timeout

Data Type Definition TimeInterval

Description The parameter timeout specifies the maximum waiting time between the times when
the service is called and when the minimum number of VC shall have been received.

In case of an infinite timeout period the service shall never return, unless a message
is received.

Domain Values timeout ≥ 0 or timeout = ‘infinite’

Prerequisite Conditions:

A VC is attached to any local VC Id addressed. This VC shall be defined for receiving direction.

Associated Calls:

NATO UNCLASSIFIED 158

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- receiveMessage,

- receiveMessageNonblocking,

- receiveBuffer.

11.4.8 File Handling Services

11.4.8.1 createDirectory

Purpose:

Creates the directory specified in the parameter list.

Syntax:

ResourceReturnStatus createDirectory (
in CharacterSequence name ,
in AccessRights access );
Description:

This service shall create a directory specified by the parameter name. The access rights specify the
usage of the directory for other users (the owner is always the creating process and has complete
access rights). If the access parameter is set to the ‘default’ value, the directory shall inherit the
access rights assigned to its parent directory.

A return status of:

- ‘RS_SUCCESS’ indicates that the directory was created successfully,

- ‘RS_RESOURCE’ indicates that the directory already exists,

- ‘RS_ERROR’ indicates that the directory was not created.

Parameter Description:

name

Data Type Definition CharacterSequence

Description The unique name to be given to the directory to be created.

Domain Values There is an OS determined length limitation for a CharacterSequence.

access

Data Type Definition AccessRights

Description ‘R’: Read

‘W’: Write

‘D’: Delete

‘F’: deFault

NATO UNCLASSIFIED 159

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None.

Associated Calls:

- deleteDirectory.

11.4.8.2 deleteDirectory

Purpose:

Deletes the directory specified in the parameter list.

Syntax:

TimedReturnStatus deleteDirectory (
in CharacterSequence name ,
in DeleteOption del_opt ,
in TimeInterval timeout );
Description:

This service shall delete the named directory with all its files and, in addition, the tree of its
subdirectories, if existing.

If the parameter del_opt is specified as ‘NORMAL’, the directory and any underlying subdirectories
shall only be deleted if all the files that they contain have been closed. However, if the deletion option
is specified as ‘IMMEDIATELY’ the directory(ies) will be deleted regardless of the status of the files
contained within them. It should be noted that the deletion option ‘IMMEDIATELY’ should only be
used in cases of emergency!

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates that the directory was successfully deleted,

- ‘TM_TIMEOUT’ indicates that the deletion option used was ‘NORMAL’ and the directory could not
be deleted due to one or more files in the directory(ies) being open,

- ‘TM_ERROR’ indicates that the directory was not deleted.

Parameter Description:

name

Data Type Definition CharacterSequence

Description A directory is identified by a unique name.

Domain Values There is an OS determined length limitation for a CharacterSequence.

del_opt

Data Type Definition enum (NORMAL, IMMEDIATELY} DeleteOption

NATO UNCLASSIFIED 160

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Specifies the urgency behind the need to delete the directory.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to delete a directory in the case when a
delete option of ‘NORMAL’ is used.

Domain Values timeout  0.0

Prerequisite Conditions:

The directory being deleted must have previously been created.

Associated Calls:

- createDirectory.

11.4.8.3 createFile

Purpose:

This service shall create a file with the name specified in the parameter list.

Syntax:

ResourceReturnStatus createFile (
in CharacterSequence name ,
in AccessRights access ,
in unsigned long file_size );
Description:

The access rights specify the usage of the file for other users (the owner is always the creating
process and has complete access rights). If nothing is specified, the file shall inherit the directory’s
access rights.

The parameter file_size shall allocate the space needed for the file during creation. The ‘end-of-file’
shall point to this value. If the parameter ‘file_size’ is set to 0, the space shall be allocated dynamically
when accessing a position beyond the current end-of-file on the occasion of a write or seek call. If a
directory path is not included in the pathname, the file shall be created in the root directory.

A return status of:

- ‘RS_SUCCESS’ indicates that the file was created successfully,

- ‘RS_RESOURCE’ indicates that the file already exists,

- ‘RS_ERROR’ indicates that the file was not created.

Parameter Description:

name

NATO UNCLASSIFIED 161

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition CharacterSequence

Description The unique name to be given to the file to be created.

Domain Values There is an OS determined length limitation for a CharacterSequence.

access

Data Type Definition AccessRights

Description ‘R’: Read

‘W’: Write

‘D’: Delete

‘F’: deFault

Domain Values No special values are associated with this parameter.

file_size

Data Type Definition Unsigned long

Description The size in bytes of the file to be created.

Domain Values >= 0

Prerequisite Conditions:

If the file being created is to be located in a sub directory off the root directory, then the directory must
exist.

Associated Calls:

- deleteFile.

11.4.8.4 deleteFile

Purpose:

This service shall delete a file addressed by its name.

Syntax:

TimedReturnStatus deleteFile (
in CharacterSequence name ,
in DeleteOption del_opt ,
in TimeInterval timeout ) ;
Description:

This service shall delete the named file. If the parameter ‘del_opt’ is specified as ‘NORMAL’, the file
will only be deleted if all the file is not being accessed by any other users. However, if the deletion
option is specified as ‘IMMEDIATELY’ the file will be deleted regardless of them being accessed by
other users. It should be noted that the deletion option ‘IMMEDIATELY’ should only be used in cases
of emergency!

NATO UNCLASSIFIED 162

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates that the file was successfully deleted,

- ‘TM_TIMEOUT’ indicates that the deletion option used was ‘NORMAL’ and that the file could not
be deleted during the timeframe specified by the timeout parameter due to the file being accessed
by another user,

- ‘TM_ERROR’ indicates that the file was not deleted.

Parameter Description:

name

Data Type Definition CharacterSequence

Description The unique name to be given to the file to be deleted.

Domain Values There is an OS determined length limitation for a CharacterSequence.

del_opt

Data Type Definition Enum (NORMAL, IMMEDIATELY} DeleteOption

Description Specifies the urgency behind the need to delete the file.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to delete a file in the case when a delete
option of ‘NORMAL’ is used.

Domain Values timeout  0.0

Prerequisite Conditions:

The file has been created.

Associated Calls:

- createFile.

11.4.8.5 openFile

Purpose:

This service shall open a file addressed by its pathname and returns the file handle for further
processing.

Syntax:

ReturnStatus openFile (

NATO UNCLASSIFIED 163

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in CharacterSequence name ,
in UseOption use_option ,
out PrivateId file_handle );
Description:

The ‘use option’ specifies whether the file is to be used for reading or writing or both. Also the
concurrency with other user (processes) is specified: there is shared / exclusive use possible –

A process may open a file more than once in order to access it in different ways, e.g. reading byte
sets sequentially from a starting point somewhere and writing conditionally to the end of the file
(append).

Each call to openFile creates an "instance" which holds the values specified by the open parameters -
in addition, the internal variables "current byte position" and "next byte position" are assigned to the
instance, as well as the locking parameters. They are used when calling the seekFile, readFile and
writeFile services. The “current byte position” shall be set to the start-of-file.

A ReturnStatus of:

- ‘SUCCESS’ indicates that the file was successfully opened,

- ‘ERROR’ indicates that the file was not opened.

Parameter Description:

name

Data Type Definition CharacterSequence

Description The unique name of the file to be opened.

Domain Values There is an OS determined length limitation for a CharacterSequence.

use_option

Data Type Definition struct {

enum (READ, WRITE, READWRITE),

enum (SHARE, EXCLUSIVE)

} UseOption

Description SHARE: More than one open allowed

Exclusive: To be opened for exclusive use

Domain Values No special values are associated with this parameter.

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

NATO UNCLASSIFIED 164

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

File has been created.

Associated Calls:

- closeFile.

11.4.8.6 closeFile

Purpose:

This service shall close the file addressed by its handle.

Syntax:

ReturnStatus closeFile (
in PrivateId file_handle ) ;
Description:

A ReturnStatus of:

- ‘SUCCESS’ indicates that the file was successfully closed,

- ‘ERROR’ indicates that the file was not closed.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

Prerequisite Conditions:

File is open.

Associated Calls:

- openFile.

11.4.8.7 lockFile

Purpose:

This service shall lock a file completely and thus prevent any other from using it.

Syntax:

TimedReturnStatus lockFile (
in PrivateId file_handle ,
in TimeInterval timeout ) ;

NATO UNCLASSIFIED 165

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description:

The file handle identifies a file. Files shall always be locked in an "exclusive" method.

Exclusive: The holder of the lock denies access. A concurrent accessor who tries to lock in any mode
is refused.

If the lock is refused, the caller is blocked if a non-zero "timeout" is specified. After its current holder
has released the lock, the caller shall become the new lock holder.

A file specified by its file handle shall have only one lock at any given time.

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates that the file was successfully locked,

- ‘TM_TIMEOUT’ indicates that the file could not be locked during the timeframe specified by the
timeout parameter due to the file being accessed by another user,

- ‘TM_ERROR’ indicates that the file was not locked.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to lock a file in the case when another user is
using it.

Domain Values timeout  0.0

Prerequisite Conditions:

File has been created and opened.

Associated services:

- unlockFile.

11.4.8.8 unlockFile

Purpose:

This service shall unlock a previously locked file.

Syntax:

ReturnStatus unlockFile (

NATO UNCLASSIFIED 166

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in PrivateId filehandle ) ;
Description:

Unlocks the previously locked file identified by the file handle.

A ReturnStatus of:

- ‘SUCCESS’ indicates that the file was successfully unlocked,

- ‘ERROR’ indicates that the file was not unlocked.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

Prerequisite Conditions:

File has been created, opened and a file has been locked.

Associated Calls:

- lockFile.

11.4.8.9 getFileAttributes

Purpose:

This service returns the access rights and the lock status.

Syntax:

ReturnStatus getFileAttributes (
in PrivateId filehandle ,
out AccessRights access ,
out LockStatus lock_status );
Description:

Allows the caller to retrieve the access rights attributed to a file and to determine if the file is locked
and if so, by whom.

A ReturnStatus of:

- ‘SUCCESS’ indicates a successful completion of the service,

- ‘ERROR’ indicates that the service did not complete successfully.

Parameter Description:

file_handle

NATO UNCLASSIFIED 167

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

access

Data Type Definition AccessRights

Description ‘R’: Read

‘W’: Write

‘D’: Delete

‘F’: deFault

Domain Values No special values are associated with this parameter.

lock_status

Data Type Definition LockStatus

Description Provides the locking status of the file.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The file has been created and opened.

Associated Calls:

None

11.4.8.10 seekFile

Purpose:

This service shall seek a new "byte position" inside the file specified by its file_handle.

Syntax:

ReturnStatus seekFile (
in PrivateId filehandle ,
in SeekMode seek_mode ,
in long set_pos ,
out unsigned long new_pos );
Description:

The byte position is defined as a byte-pointer starting at zero ranging to the current end-of-file. The
parameter seek_mode specifies the byte position to start seeking from at either the start-of-file, at the
current value of the byte position or indeed the end-of-file.

NATO UNCLASSIFIED 168

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value of the out parameter new_pos is dependent on the values of the input parameters:
seek_mode and set-pos. The permitted values of set-pos are also dependent on the value of seek-
mode:

Table 22 – APOS File Seek Modes

Seek_mode Set_pos (Permitted values) Value of new_pos

START_OF_FILE 0 .. file_size Set_pos

CURRENT_POSITION -Current_Position .. (file_size – Current_Position)) Current_Position + set_pos

END_OF_FILE -file_size .. 0 File_size + set_pos

A ReturnStatus of:

- ‘SUCCESS’ indicates a successful completion of the service,

- ‘ERROR’ indicates that the service did not complete successfully.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

seek_mode

Data Type Definition enum {

START_OF_FILE,
CURRENT_POSITION,

END_OF_FILE

} SeekMode;

Description Used as a base pointer for positioning the byte pointer.

Domain Values No special values are associated with this parameter.

set_pos

Data Type Definition long

Description Used as an offset to from the base pointer when positioning the byte pointer.

Domain Values -file_size .. file_size

new_pos

NATO UNCLASSIFIED 169

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition unsigned long

Description The new position of the byte pointer.

Domain Values 0 .. file_size

Prerequisite Conditions:

The file shall have been created and opened.

Associated Calls:

None

11.4.8.11 readFile

Purpose:

This service shall read the contents of the file specified by its handle into the buffer

Syntax:

TimedReturnStatus readFile (
in PrivateId filehandle ,
out Address buffer_address ,
in long read_count ,
out long count_read ,
in TimeInterval timeout ) ;
Description:

The content to be read is limited by read_count the actual count of bytes is returned in count_read.
The value of ‘count_read’ differs from the ‘read_count’ value only if the start-of-file or the end-of-byte
position is exceeded.

Reading starts at the "current byte position" specified by the preceding call to seekFile, readFile or
writeFile.

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates that the file was successfully read from,

- ‘TM_TIMEOUT’ indicates that the file could not be read from during the timeframe specified by the
timeout parameter due to the file being accessed by another user,

- ‘TM_ERROR’ indicates that the file was not read.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

NATO UNCLASSIFIED 170

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

buffer_address

Data Type Definition Address

Description The address of the buffer that data read from a file is copied to.

Domain Values No special values are associated with this parameter.

read_count

Data Type Definition unsigned long

Description The number of bytes to be read.

Domain Values No special values are associated with this parameter.

count_read

Data Type Definition unsigned long

Description The actual number of bytes read.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to read a file in the case when another user is
using it.

Domain Values timeout  0.0

Prerequisite Conditions:

The file shall have been created and opened.

Associated Calls:

- writeFile.

11.4.8.12 writeFile

Purpose:

This service shall write the contents of the buffer with the length of parameter write_count to the file
specified by its handle.

Syntax:

TimedReturnStatus writeFile (
in privateId file_handle ,
in address buffer_address ,
in unsigned long write_count ,

NATO UNCLASSIFIED 171

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

out unsigned long count_written ,

in TimeInterval timeout ) ;
Description:

The contents to be written are limited by parameter write_count, the actual count of bytes is returned
in parameter count_written. Writing starts at the ‘Current Byte Position’ specified by the preceding call
to seekFile, readFile or writeFile.

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates that the file was successfully written to,

- ‘TM_TIMEOUT’ indicates that the file could not be written to during the timeframe specified by the
timeout parameter due to the file being accessed by another user,

- ‘TM_ERROR’ indicates that the file was not written to.

Parameter Description:

file_handle

Data Type Definition PrivateId

Description The handle to use when accessing the file.

Domain Values >= 0

buffer_address

Data Type Definition Address

Description The address of the buffer that data to be written to is copied form.

Domain Values No special values are associated with this parameter.

write_count

Data Type Definition unsigned long

Description The number of bytes to be written.

Domain Values No special values are associated with this parameter.

count_written

Data Type Definition unsigned long

Description The actual number of bytes written.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to write to a file in the case when another

NATO UNCLASSIFIED 172

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

user is using it.

Domain Values timeout  0.0

Prerequisite Conditions:

The file shall have been created and opened.

Associated Calls:

- readFile.

11.4.8.13 getFileBuffer

Purpose:

Reserves an area of memory for accessing files.

Syntax:

TimedReturnStatus getFileBuffer (
in unsigned long buffer_size ,
out Address buffer_address ,
in TimeInterval timeout ) ;
Description:

Reserves memory (a buffer) used in accessing a file. Data to be written to a file is first written to a
buffer and then copied across to the File on the execution of the writeFile service. Similarly, when
reading a file (readFile service), the data read is coped to the buffer. If no buffer is available the
service shall block until either a buffer has become available or the time-out has been reached. The
memory shall not be dynamically allocated, as buffers are static and fixed in terms of number and
length.

A TimedReturnStatus of:

- ‘TM_SUCCESS’ indicates a successful completion of this service,

- ‘TM_TIMEOUT’ indicates that a buffer could not be released during the timeframe specified by the
timeout parameter,

- ‘TM_ERROR’ indicates that the address of the buffer was not returned.

Parameter Description:

buffer_size

Data Type Definition unsigned long

Description The size of the buffer that is to be used to access a file.

Domain Values No special values are associated with this parameter.

buffer_address

Data Type Definition Address

NATO UNCLASSIFIED 173

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The address of the buffer that is to be used to access a file.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The maximum time the service will wait to write to get a buffer.

Domain Values timeout  0.0

Prerequisite Conditions:

None

Associated Calls:

- releaseBuffer.

11.4.8.14 releaseFileBuffer

Purpose:

Releases an area of memory used for accessing files.

Syntax:

ReturnStatus releaseFileBuffer (
in Address buffer_address ) ;
Description:

Releases the memory reserved by the service getFileBuffer.

A ReturnStatus of:

- ‘SUCCESS’ indicates a successful completion of this service,

- ‘ERROR’ indicates that the buffer could not be released.

Parameter Description:

buffer_address

Data Type Definition Address

Description The address of the buffer that is to be used to access a file.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The buffer being released must have previously been created.

Associated Calls:

NATO UNCLASSIFIED 174

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- getFileBuffer.

11.4.9 Power Conversion Services

11.4.9.1 setPowerSwitch

Purpose:

Inform the OS to request the setting of a power switch.

Syntax:

ReturnStatus setPowerSwitch (
in PublicId switch_id ,
in SwitchOp switch_op );
Description:

The service shall be used to inform the OS to request that a power switch is to be set to a specified
state. The OS shall do this by means of MOS service setPowerSwitch.

An ‘ERROR’ condition shall be returned if the request fails. Otherwise the return status shall be
‘SUCCESS’.

Parameter Description:

switch_id

Data Type Definition PublicId

Description Identifier for the relevant power switch

Domain Values No special values are associated with this parameter.

switch_op

Data Type Definition SwitchOp

Description Enumeration for the switch state

Domain Values All values of the enumerated type SwitchOp.

Prerequisite Conditions:

None

Associated Calls:

- resetPowerSwitches,

- getPowerSwitchStatus.

11.4.9.2 resetPowerSwitches

Purpose:

NATO UNCLASSIFIED 175

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Inform the OS to request the resetting of all power switches.

Syntax:

ReturnStatus resetPowerSwitches ();

Description:

The service shall be used to inform the OS to request that all power switches on this CFM are to be
reset to the OFF state. The OS shall do this by means of MOS service resetPowerSwitch.

An ‘ERROR’ condition shall be returned if the request fails. Otherwise the return status shall be
‘SUCCESS’.

Parameter Description:

No parameters are required.

Prerequisite Conditions:

None

Associated Calls:

- setPowerSwitch,

- getPowerSwitchStatus.

11.4.9.3 getPowerSwitchStatus

Purpose:

Get the current status of the power switch.

Syntax:

ReturnStatus getPowerSwitchStatus (
out PowerSwitch power_switch );
Description:

The service shall be used to retrieve the complete Status of all power switches on this CFM state. The
OS shall do this by means of MOS service getPowerSwitchStatus.

An ‘ERROR’ condition shall be returned if the request fails.

Otherwise the return status shall be ‘SUCCESS’.

Parameter Description:

power_switch

Data Type Definition PowerSwitch

Description Structure including the switch_id and the SwitchStat structure.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 176

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

None

Associated Calls:

- setPowerSwitch,

- resetPowerSwitches.

11.5 MOS

The MSL to OSL (MOS) interface defines a set of services that provide hardware independence and
allow the OS software to access the resources that reside on a CFM. The location of the MOS within
the software architecture is shown in Figure 50.

Apps & App

Manager
APOS

OSL
MOS
MSL

CFM Hardware

Figure 50 - Software Architecture Model - Three-Layer Stack (TLS)

Functional components within the MOS are shown in Figure 51.

GPM PCM MMM

Services Services Services

Board Communication
Services Services Extension
Specific Services
Core Services Services

Generic MOS

MOS

Figure 51 - MOS Software Architecture Model

The MOS, which shall be compliant with the three layer architectural model as specified in the ASAAC
Software Standard, shall be formed by the combination of the Generic MOS and the OS specific
extension. The use of extensions shall not affect the implementation of the other interfaces in the
software architecture.

The MOS services are grouped as follows and for details on them the section is given:

NATO UNCLASSIFIED 177

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Generic MOS, which itself is split into,

- Core Services, which are common across all module types, and are themselves split into,

- Board services - covering the services related to on-module resources external to the
processor. They are specified in section 11.5.1.2,

- Communication services - covering the services related to communications between

processors whether on the same module or between modules. They are specified in section
11.5.1.3,

- Specific services, which specifies sets of services particular to the GPM (see section
11.5.2.1), PCM (see section 11.5.2.2) and MMM (see section 11.5.2.3).

- Extended services -

- Bespoke Extension - which includes provision for portability of a bespoke ASAAC OS from
one processor to another one (see section 11.5.3).

11.5.1 Generic MOS

11.5.1.1 Core Services

The Core MOS services shall provide access to the on-module resources that are external to the
processor. These services, as listed below, shall be available on every module type.

Table 23 - Core MOS Services

Service Type MOS Services Description Section

Timer getAbsoluteLocalTime 11.5.1.2.1.

Get aircraft system time (ALT)
1

getRelativeLocalTime 11.5.1.2.1.
Get module time (RLT)
2

getAbsoluteGlobalTime 11.5.1.2.1.
Get external reference time (AGT)
3

configureClock 11.5.1.2.1.
Configure the clock mode of the Module
4

attachFederatedClock Attach a federated clock to the Module 11.5.1.2.1.

clock 5

setupTimer 11.5.1.2.1.
Setup timer
6

startTimer 11.5.1.2.1.
Start timer activity
7

stopTimer 11.5.1.2.1.
Stop timer activity 8

NATO UNCLASSIFIED 178

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Type MOS Services Description Section

readTimer 11.5.1.2.1.
Read a timer
9

Device readLogDevice 11.5.1.2.2.

Read from Log Device
Services 1

writeLogDevice 11.5.1.2.2.
Write to Log Device
2

erasePhysicalMemory Instigate the erasure of CFM physical 11.5.1.2.2.

memory 3

Callback registerCallback Register a callback/interrupt handler with 11.5.1.2.3.

Services an event 1

enableCallback 11.5.1.2.3.
Enables a callbacks use.
2

disableCallback 11.5.1.2.3.
Disables a callbacks use.
3

deleteCallback Remove a registered callback from the 11.5.1.2.3.

MSL 4

callbackHandler 11.5.1.2.3.
This is the callback handler template.
5

BIT getPbitResult Get Power Up BIT results via network 11.5.1.2.4.

remote CFM 1

getCbitResult 11.5.1.2.4.
Get Continuous BIT result
2

startIbit 11.5.1.2.4.
Start Initiated BIT
3

getIbitResult 11.5.1.2.4.
Get Initiated BIT Result
4

startCbit This service starts the continuous built-in 11.5.1.2.4.

test monitoring 5

CFM Resource getCfmInfo 11.5.1.2.5.

Get CFM Information
1

getCfmStatus 11.5.1.2.5.
Get CFM Status
2

getMyPeId Get the PE ID from which the service is 11.5.1.2.5.

called. 3

getPeInfo 11.5.1.2.5.
Get the PE information of own PE.
4

NATO UNCLASSIFIED 179

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Type MOS Services Description Section

Communication configureInterface Configure a local communication 11.5.1.3.1

Services interface

Configure the local resource to handle 11.5.1.3.2

configureTransfer the transmission or reception of
information over a TC

sendTransfer Send a block of data on the given TC 11.5.1.3.3

receiveTransfer Collect a block of data received by the 11.5.1.3.4

MSL on the given TC

Release local resources previously 11.5.1.3.5

destroyTransfer allocated to handle the transmission or
reception of information over a TC

getNetworkPortStatus Determine the status of a network. 11.5.1.3.6

receiveNetwork Receives data from a network on any 11.5.1.3.7

TC.

11.5.1.2 Board Services

11.5.1.2.1 Timer services

11.5.1.2.1.1 getAbsoluteLocalTime

Purpose:

Provide the absolute local time value.

Syntax:

TimerReturnStatus getAbsoluteLocalTime (
out Time ac_system_time );
Description:

This service conveys the absolute local time (current aircraft system) as distributed within the ASAAC
core system in seconds and nanoseconds.

The value MOS_TIMER_CALL_OK shall be returned by the service if it could return a valid time value.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not return a valid
time value, either because the system is not yet synchronised or for any other reason.

Parameter Description:

ac_system_time

Data Type Definition Time

NATO UNCLASSIFIED 180

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Aircraft system time.

Domain Value No special values are associated with this parameter.

Associated Calls:

- getRelativeLocalTime,

- getAbsoluteGlobalTime.

11.5.1.2.1.2 getRelativeLocalTime

Purpose:

Provide the relative local time value.

Syntax:

TimerReturnStatus getRelativeLocalTime(
out Time cfm_time );
Description:

The getRelativeLocalTime function shall be used to get the current CFM time measured in
seconds and nanoseconds. In order to get realistic time values, the execution time of this service shall
be limited. Thus, an appropriate time distribution mechanism shall be defined (project dependent).

The value MOS_TIMER_CALL_OK shall be returned by the service if it could return a valid time value.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not return a valid
time value, either because the system is not yet synchronised or for any other reason.

Parameter Description:

cfm_time

Data Type Definition Time

Description CFM RLT

Domain Values No special values are associated with this parameter.

Associated Calls:

- getAbsoluteLocalTime,

- getAbsoluteGlobalTime.

11.5.1.2.1.3 getAbsoluteGlobalTime

Purpose:

Provide the absolute global time value.

Syntax:

NATO UNCLASSIFIED 181

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

TimerReturnStatus getAbsoluteGlobalTime (
out Time absolute_global_time ) ;
Description:

This service conveys the absolute global time value as distributed within the ASAAC core system in
seconds and nanoseconds.

The value MOS_TIMER_CALL_OK shall be returned by the service if it could return a valid time value.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not return a valid
time value, either because the system is not available yet.

Parameter Description:

absolute_global_time

Data Type Definition Time

Description This value provides the absolute global time (i.e. the synchronised time from
outside the system) valid at the point of return from the service.

This time is guaranteed to be strictly monotonously.

Domain Values No special values for this service.

Prerequisite Conditions:

Absolute global time is available.

Associated Calls:

- getRelativeLocalTime,

- getAbsoluteLocalTime.

11.5.1.2.1.4 configureClock

Purpose:

Configure the clock mode of the Module.

Syntax:

TimerReturnStatus configureClock (
in ClockInfo clock_info ) ;
Description:

The service shall be used to configure the mode of the clock of the Module. The structure is passed to
the MSU that supports the resources related to the time management. It assigns the Clock Mode and
data configuring the management of the Absolute Global Time and the synchronisation of the
Absolute Local Time, which is dependent on the synchronisation method.

The Clock Mode determines the hierarchal position in the IMA System that drives the MLI protocol.
Depending on its position, the MSL shall send request or reply MLI messages related to the time
management. Details on MLI Protocol are fully specified in section 12.7.

NATO UNCLASSIFIED 182

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The Clock Identifier shall be used when logging message for ITM diagnostic.

When the clock has been configured, it is started without waiting for the configuration of federated
clocks. If the service is performed twice, it shall overlap the previous clock configuration as well as the
configuration of all federated clocks.

A MOS_TIMER_CALL_FAILED condition shall be returned when the configuration the clock mode has
failed.

The service shall return MOS_TIMER_CALL_OK on successful completion.

Parameter Description:

clock_info

Data Type Definition ClockInfo

Description It describes the properties of a module local clock.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- attachFederatedClock.

11.5.1.2.1.5 attachFederatedClock

Purpose:

Attach a federated clock to the Module clock.

Syntax:

TimerReturnStatus attachFederatedClock (
in FederatedClockInfo federated_clock_info );
Description:

The service shall be used to attach a federated clock to the Module clock. The structure is passed to
the MSU that supports the resources related to the time management.

It assigns information to handle the protocol MLI between the Module Clock and a remote federated
clock. Details on MLI Protocol are fully specified in section 12.7.

The service shall be performed for each federated clock. The configuration of federated clocks is
independent of each other. It means there is no need to wait for the configuration of all federated
clocks before starting the MLI protocol.

The Clock Identifier and Clock Mode shall be used when logging message for ITM diagnostic.

A MOS_TIMER_CALL_FAILED condition shall be returned when:

- The attachment has failed for any reasons,

NATO UNCLASSIFIED 183

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- The federated clock has already been attached,

- The service configureClock has not been previously performed.

The service shall return MOS_TIMER_CALL_OK on successful completion.

Parameter Description:

federated_clock_info

Data Type Definition FederatedClockInfo

Description This structure provides the properties of a federated clock.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The service configureClock has not been previously performed. The Federated Clock is not attached

Associated Calls:

- configureClock.

11.5.1.2.1.6 setupTimer

Purpose:

Sets up a timer service.

Syntax:

TimerReturnStatus setupTimer (
in PublicId timer_id ,
in Time time_to_expire ,
in Callback callback_id ,
in AlarmType alarm_type );
Description:

The setupTimer function shall be used to set the following attributes of a timer before its use:

- time_tick_duration,

- alarm_type.

The timer may be used for CFM local time measurements (e.g. for OS scheduling).

The timer_id shall be used to identify the timer for which the set-up shall be applied. The service
getCfmInfo shall be used to get the set of timer IDs. The function startTimer shall be used to
start the timer.

The value MOS_TIMER_CALL_OK shall be returned by the service if it could successfully set up the
timer.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not set up the timer,
either because the system is out of resources or any other reason.

NATO UNCLASSIFIED 184

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Parameter Description:

timer_id

Data Type Definition PublicId

Description Timer identification

Domain Values No special values are associated with this parameter.

time_tick_duration

Data Type Definition unsigned long

Description Duration for a time tick in s

Domain Values 1..232-1 ticks

callback_id

Data Type Definition Callback

Description Identifier of the callback in case of timer expiration.

Domain Values 1..232-1 ticks

alarm_type

Data Type Definition AlarmType

Description Alarm type of timer.

Domain Values No special values are associated with this parameter.

Associated Calls:

- getCfmInfo,

- startTimer,

- stopTimer,

- readTimer,

- getRelativeLocalTime,

- registerCallback,

- enableCallback,

- disableCallback.

11.5.1.2.1.7 startTimer

Purpose:

NATO UNCLASSIFIED 185

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Start a configured timer.

Syntax:

TimerReturnStatus startTimer (
in PublicId timer_id);
Description:

The startTimer function shall be used to start the timer activity.

The timer may be used for CFM local time measurements (e.g. for OS scheduling).

The timer_id shall be used to identify the timer for which the operation shall be applied. The service
getCfmInfo shall be used to get the timer_id.

The value MOS_TIMER_CALL_OK shall be returned by the service if it could successfully start the
timer.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not start the timer,
either because the system is out of resources or for any other reason.

Parameter Description:

timer_id

Data Type Definition PublicId

Description Timer identification

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The timer shall be correctly set up before using the setupTimer service.

Associated Calls:

- getCfmInfo,

- setupTimer,

- stopTimer,

- readTimer,

- getRelativeLocalTime,

- registerCallback,

- enableCallback,

- disableCallback.

11.5.1.2.1.8 stopTimer

Purpose:

NATO UNCLASSIFIED 186

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Stops a running timer.

Syntax:

TimerReturnStatus stopTimer (
in PublicId timer_id );
Description:

The stopTimer function shall be used to stop the timer activity.

The timer_id shall be used to identify the timer for which the set-up shall be applied.

The timer function shall be resumed with the function startTimer

The value MOS_TIMER_CALL_OK shall be returned by the service if it could stop the timer
successfully.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not stop the timer,
either because of wrong Id or any other reason.

Parameter Description:

timer_id

Data Type Definition PublicId

Description Timer identification

Domain Values No special values are associated with this parameter.

Associated Calls:

- getCfmInfo,

- setupTimer,

- startTimer,

- readTimer,

- getRelativeLocalTime,

- registerCallback,

- enableCallback,

- disableCallback.

11.5.1.2.1.9 readTimer

Purpose:

Reads a running timer.

Syntax:

NATO UNCLASSIFIED 187

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

TimerReturnStatus readTimer (
in PublicId timer_id ,
out Time time_to_expire );
Description:

The readTimer function shall be used to read the current timer value (time to expire).

The timer_id shall be used to identify the timer for which the set-up shall be applied.

The value MOS_TIMER_CALL_OK shall be returned by the service if it could return a valid timer
expiration time.

The value MOS_TIMER_CALL_FAILED shall be returned by the service if it could not read the timer,
either because of wrong Id or any other reason (e.g. not started).

Parameter Description:

timer_id

Data Type Definition PublicId

Description Timer identification

Domain Values No special values are associated with this parameter.

time_to_expire

Data Type Definition Time

Description Time until the timer expires.

Domain Values No special values are associated with this parameter.

Associated Calls:

- getCfmInfo,

- setupTimer,

- startTimer,

- getRelativeLocalTime,

- registerCallback,

- enableCallback,

- disableCallback.

11.5.1.2.2 Device Services

11.5.1.2.2.1 readLogDevice

Purpose:

NATO UNCLASSIFIED 188

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This service reads a message through the MOS from memory.

Syntax:

ResourceReturnStatus readLogDevice (
in LogMessageType message_type ,
in unsigned long log_id ,
out CharacterSequence log_message );
Description:

This call reads the character string log_message from a dedicated local log. The message_type
identifies the log being read from and the log_id identifies the position within that log. A log_id of Null
will read from the end of the particular log. Log_id is unique to a message_type.

This service returns RS_SUCCESS if the message is successfully read. If the service does not read
successfully, RS_RESOURCE is returned if there are resource limitations, such as the log not being
found or not being available, otherwise it shall return RS_ERROR.

Parameter Description:

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

log_id

Data Type Definition unsigned long

Description This parameter identifies where the message is to be read from memory of a
particular log.

Domain Values Null if the message is to be read from the end of a message log.

log_message

Data Type Definition CharacterSequence

Description The sequence of characters that is read.

Domain Values A NUL character terminates the message.

Prerequisite Conditions:

None.

Associated Calls:

- writeLogDevice.

11.5.1.2.2.2 writeLogDevice

Purpose:

NATO UNCLASSIFIED 189

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This service writes a message through the MOS into memory.

Syntax:

ResourceReturnStatus writeLogDevice (
in LogMessageType message_type ,
in unsigned long log_id ,
in CharacterSequence log_message );
Description:

This call stores the passed character string into a dedicated local log using the given log_id. The
message_type identifies which message log is being written to. The log_id identifies the location in
memory within that log. If a null is given as the log_id then the OS shall append the message to the
specified log. Log_id is unique to a message_type.

This service returns RS_SUCCESS if the message is written successfully. If the service fails to
successfully write the message it shall return RS_RESOURCE if there are resource limitations such
as the log is full, not found or not available; otherwise it shall return RS_ERROR.

Parameter Description:

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

log_id

Data Type Definition unsigned long

Description This parameter identifies where the message is to be written to in a message log.

Domain Values Null if the message is to be appended to the end of a message log.

log_message

Data Type Definition CharacterSequence

Description The sequence of characters that is written

Domain Values A NUL character terminates the message.

Prerequisite Conditions:

None.

Associated Calls:

- readLogDevice.

11.5.1.2.2.3 erasePhysicalMemory

Purpose:

NATO UNCLASSIFIED 190

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This service shall instigate the erasure of physical memory on the CFM where the calling
Configuration Manager resides.

Syntax:

ReturnStatus erasePhysicalMemory ();

Description:

An ‘ERROR’ condition shall be returned when the service has not been performed correctly.

Otherwise there will be no return status ‘SUCCESS’ since the memory has disappeared.

This call shall be used when it is necessary to quickly erase the physical memory on a given CFM.
The action will be instigated by the CM, which will use this SMOS call through to the OS, which will
then use a reflected MOS call through to the MSL. It is expected that the actual erasure will be
executed in hardware.

Parameter Description:

None.

Prerequisite Conditions:

None.

Associated Calls:

None.

11.5.1.2.3 Callback Services

The MOS callback services shall provide the MSL with a means of signalling asynchronous events (e.
g. interrupts) to the OSL. The address of the software to be invoked upon an event occurring is
passed to the MSL. The interrupts due to these events may also be temporarily suspended (e.g.
during the servicing of a different interrupt).

11.5.1.2.3.1 registerCallback

Purpose:

Associate a callback handler with a callback event.

Syntax:

MSLstatus registerCallback (
in EventType event_type ,
in PublicId callback_id ,
in Address callback );
Description:

A callback is an asynchronous mechanism used to notify other entities about MSL events. The
callback parameter is a pointer to a function that is associated with the event event_id. The
callback_id parameter is used to distinguish instantiations of the same event type. When the event
occurs the function call is performed. Events considered are described under the callbackHandler
function Description

NATO UNCLASSIFIED 191

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service call completes before calling process continues. When a callback has been registered it shall
be enabled using the enableCallback service before it can be used.

The service will return MSL_OK if the callback is registered correctly.

The service will return MSL_CALLBACK_INVALID_PARAMETER if any of the parameters are deemed
to be incorrect.

The service will return MSL_CALLBACK_FAILED if there is any other problem.

Parameter Description:

event_type

Data Type Definition EventType

Description Type of event the callback is associated with.

Domain Values There is no limitation for this service.

callback_id

Data Type Definition PublicId

Description The callback identity used by the OS to distinguish between callbacks of the same
event type.

Domain Values There is no limitation for this service.

callback

Data Type Definition Address

Description The address of the callback handler function that this callback will instigate.

Domain Values There is no limitation for this service.

Prerequisite Conditions:

The Callback Address must point to a valid Callback Handler procedure.

Associated Calls:

- enableCallback,

- disableCallback,

- deleteCallback.

11.5.1.2.3.2 enableCallback

Purpose:

The enableCallback function shall be used to enable a specified callback.

Syntax:

NATO UNCLASSIFIED 192

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MSLstatus enableCallback (
in EventType event_type ,
in PublicId callback_id );
Description:

This allows a callback to be enabled such that the MSL can make use of it to signal the OS.

The service will return MSL_OK if the callback is enabled correctly.

The service will return MSL_CALLBACK_INVALID_PARAMETER if the parameter is not a registered

callback.

The service will return MSL_CALLBACK_FAILED if there is any other problem.

Parameter Description:

event_type

Data Type Definition EventType

Description Type of event the callback is associated with.

Domain Values It must be an event type that has already been registered.

callback_id

Data Type Definition PublicId

Description The callback identity used by the OS to distinguish between callbacks of the same
event type.

Domain Values Values are limited to those already registered

Prerequisite Conditions:

The Callback must have been registered using registerCallback.

Associated Calls:

- registerCallback,

- disableCallback,

- deleteCallback.

11.5.1.2.3.3 disableCallback

Purpose:

The disableCallback function shall be used to disable a specified callback.

Syntax:

MSLstatus disableCallback (
in EventType event_type ,
in PublicId callback_id );

NATO UNCLASSIFIED 193

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description:

This allows a callback to be disabled such that the MSL cannot perform a callback of the associated
address function given in the registerCallback.

The service will return MSL_OK if the callback is disabled correctly.

The service will return MSL_CALLBACK_INVALID_PARAMETER if the parameter is not a registered

callback.

The service will return MSL_CALLBACK_FAILED if there is any other problem.

Parameter Description:

event_type

Data Type Definition EventType

Description Type of event the callback is associated with.

Domain Values It must be an event type that has already been registered.

callback_id

Data Type Definition PublicId

Description The callback identity used by the OS to distinguish between callbacks of the same
event type.

Domain Values Values are limited to those already registered

Prerequisite Conditions:

The Callback must have been registered using registerCallback.

Associated Calls:

- registerCallback,

- enableCallback,

- deleteCallback.

11.5.1.2.3.4 deleteCallback

Purpose:

The deleteCallback service is used to remove a registered callback from the MSL.

Syntax:

MSLstatus deleteCallback (
in EventType event_type,
in PublicId callback_id );
Description:

NATO UNCLASSIFIED 194

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This allows the callback to be re-used by another process.

Service call completes before calling process continues.

The service will return MSL_OK if the callback is deleted correctly.

The service will return MSL_CALLBACK_INVALID_PARAMETER if the parameters are not valid.

The service will return MSL_CALLBACK_FAILED if there is any other problem.

Parameter Description:

event_type

Data Type Definition EventType

Description Type of event the callback is associated with.

Domain Values It must be an event type that has already been registered.

callback_id

Data Type Definition PublicId

Description The callback identity used by the OS to distinguish between callbacks of the same
event type

Domain Values Values are limited to those already registered

Prerequisite Conditions:

The Callback must have been registered using the registerCallback.

The Callback must have been disabled using the disableCallback.

Associated Calls:

- registerCallback,

- enableCallback,

- disableCallback.

11.5.1.2.3.5 callbackHandler

Purpose:

This is the callback handler template. It is called by the underlying MSL when a callback event has
occurred

Syntax:

void callbackHandler (
in EventType event_type ,
in PublicId callback_id ,
in Address *event_info_data );

NATO UNCLASSIFIED 195

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description:

This will be the final item in an MSL routine generating the required callback. The routine will
complete (upon the callback being scheduled) to invoke the identified service.

This is a function for a callback/interrupt handler that shall indicate the intended use and parameters
passed. The callbackHandler is an asynchronous mechanism used to notify other entities about
MSL events. The provision of a callback is made through the registerCallback service. Events
considered here are as defined below.

COMMS_EV_ERROR

This event is not related to any specific communication service call. It is triggered when an
unexpected and unsolicited error is detected (e. g. an error which cannot be associated with a specific
TC).

Errors are notified by a more specific event type if they occur at the local network interface and can be
associated with the involved TC identifier. However, if errors are detected elsewhere or cannot be
associated with a specific TC identifier, the general COMMS_EV_ERROR event shall be triggered at the
MOS interface. This event also occurs if an error occurs in the transmission of data or no buffer is
available to hold incoming data.

COMMS_EV_INFO

Information about a network is requested through the getNetworkPortStatus call. The MSL fills
the info_data structure fields with the requested information. The COMMS_EV_INFO event is
triggered when this information is available to be collected and passed back as the EventInfoData
structure.

COMMS_EV_CONFIGURE

This event is triggered to indicate the success of a configuration (configureNetwork or

configureTransfer). The success or failure of the configure request and the associated
NetworkDescriptor or TC identifier are returned in the EventInfoData.

COMMS_EV_BUFFER_SENT

This event is triggered on a completion of a sendTransfer or configureNetwork call, if

trigger_callback was specified as TRUE in the associated configureTransfer call. The
success or failure of the configure request and the associated NetworkDescriptor or TC identifier
are returned in the EventInfoData.

The event signals that the buffer is safely reusable.

COMMS_EV_BUFFER_RECEIVED

This event is associated with data in a buffer being ready to be received, if trigger_callback was
specified as TRUE in the associated configureTransfer call. It is associated with the
receiveTransfer call. The detection of errors in the received data is indicated to the callback
handler. Then if an error has been detected, then the data will not be available.

TIMER_ALARM

This event is associated with the expiration of a timer. This event shall return the timer_id in the
EventInfoData.

CBIT_ERROR_DETECT

NATO UNCLASSIFIED 196

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This event is associated with the detection of a fault by the continuous hardware built-in test (CBIT).
The event_info_data shall be NUL, as the detailed fault report shall be obtained by the
getCbitResult service.

MMM_SD_EVENT

This callback is raised when a disk DMA transfer has completed.

Parameter Description:

event_type

Data Type Definition EventType

Description Type of event the callback is associated with.

Domain Values There is no limitation for this service.

callback_id

Data Type Definition PublicId

Description The callback identity used by the OS to distinguish between callbacks of the same
event type

Domain Values There is no limitation for this service.

event_info_data

Data Type Definition Address

Description Address of data providing information about the event, which triggered the callback
mechanism. The data type of this structure is event, and possibly network, specific.

The information contained in this structure is callback event specific.

Domain Values There is no limitation for this service.

Associated Calls:

- registerCallback,

- configureNetwork,

- configureTransfer,

- sendTransfer,

- receiveTransfer,

- sendFragmentedTransfer,

- receiveFragmentedTransfer.

NATO UNCLASSIFIED 197

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.1.2.4 BIT Services

11.5.1.2.4.1 getPbitResult

Purpose:

Gets the Power up Built In Test (PBIT) result.

Syntax:

BitReturnStatus getPbitResult (
out PbitResult pbit_result );
Description:

This service is used to retrieve the result of the previously initiated PBIT.

The value MOS_BIT_CALL_OK shall be returned by the service if it could return the requested PBIT
result (Note: Whether the result is OK or FAILED does not matter).

The value MOS_BIT_CALL_FAILED shall be returned by the service if it could not return the PBIT
result or the PBIT process was not triggered before using the service.

Service call completes before calling process continues.

Parameter Description:

pbit_result

Data Type Definition PbitResult;

Description PBIT result.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The PBIT shall have been started before this service is used to retrieve the result.

Associated Calls:

None

11.5.1.2.4.2 getCbitResult

Purpose:

Gets the Continuous Built In Test (CBIT) result.

Syntax:

BitReturnStatus getCbitResult (
out CbitResult cbit_result );
Description:

The getCbitResult function shall be used to get the Continuous Built In Test (CBIT) result.

NATO UNCLASSIFIED 198

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value MOS_BIT_CALL_OK shall be returned by the service if it could return the assigned CBIT
result (Note: whether the result is OK or FAILED does not matter).

The value MOS_BIT_CALL_FAILED shall be returned by the service if it could not return the assigned
CBIT result.

The CBIT_FINAL_RESULT_OK shall be returned if and only if all CbitDetailedResult entries

are o.k. Service call completes before calling process continues.

Parameter Description:

cbit_result

Data Type Definition CbitResult

Description CBIT result.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

CBIT started previously.

Associated Calls:

- startCbit.

11.5.1.2.4.3 startIbit

Purpose:

Starts the Initiated Built In Test (IBIT).

Syntax:

BitReturnStatus startIbit();
Description:

The value MOS_BIT_CALL_OK shall be returned by the service if it could start the IBIT process.

The value MOS_BIT_CALL_FAILED shall be returned by the service if it could not start the IBIT
process.

Service call completes before calling process continues (The IBIT process is started, but the result is
not necessarily yet available).

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

NATO UNCLASSIFIED 199

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- getIbitResult.

11.5.1.2.4.4 getIbitResult

Purpose:

Gets the Initiated Built In Test (IBIT) result.

Syntax:

BitReturnStatus getIbitResult (
out IbitResult ibit_result );
Description:

This service is used to retrieve the result of the previously initiated IBIT.

The value MOS_BIT_CALL_OK shall be returned by the service if it could return the requested IBIT
result (Note: Whether the result is OK or FAILED does not matter).

The value MOS_BIT_CALL_FAILED shall be returned by the service if it could not return the
requested IBIT result or the IBIT process was not triggered before using the startIbit service.

Service call completes before calling process continues.

Parameter Description:

ibit_result

Data Type Definition IbitResult

Description IBIT result.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The service call startIbit shall have been started before this service is used to retrieve the result.

Associated Calls:

- startIbit.

11.5.1.2.4.5 startCbit

Purpose:

This service starts the continuous built-in test monitoring.

Syntax:

ReturnStatus startCbit (
in unsigned long test_code ,
in CbitModeType mode ,
out BitTestStatus bit_test_status );

NATO UNCLASSIFIED 200

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description:

The service startCbit is used to perform a CBIT test. When the call is made the CBIT software will run
a specified test, given as an input parameter, for a predetermined period and then return. The
predetermined period will be system specific. The CBIT test software must be written to return within
this period. If the test is autonomous the call will check the state of the ongoing test and return the
status. If the test requires the processor to perform some function, the call will cause the test to be run
and will then return the status.

Some tests require that the processor will not complete within the system specific period. These are
termed partitioned tests and a complete test will take more than one call to startCbit to complete.
Therefore, when the call is made a test will be specified to be either:

COMPLETE - the call will complete within one startCbit invocation. The caller shall be blocked until
the test is finished. The OS may pre-empt this.

PARTITIONED – the call will not complete within one startCbit invocation. The OS shall not pre-empt
it.

The startCbit call returns bit_test_status that can be set to one of three values:

- PASSED – the specified test has completed and passed within the last startCbit invocation,

- ONGOING – the specified test is PARTITIONED and has not completed within the last startCbit
invocation,

- FAILED – the specified test has failed within the last startCbit invocation.

If the call returns bit_test_status as FAILED, the service getCbitResult is used to retrieve the detailed
failure information for the last test to fail.

If the startCbit call is made with the test code of zero, the CBIT software will perform all test in a
round-robin manner. In this case the call will always be set to PARTITIONED and will always set
bit_test_status as ONGOING until a failure is detected. The next invocation of startCbit, after a call
returns bit_test_status as FAILED, will recommence testing at the next test in the round-robin
sequence.

The service returns SUCCESS if CBIT is invoked correctly, otherwise it returns ERROR.

Parameter Description:

test_code

DataType Definition unsigned long

Description This is an integer value which identifies which CBIT test to run. If the code is zero the
complete set of tests is run in a cyclic fashion.

Domain Values No special values are associated with this parameter.

mode

DataType Definition CbitModeType

Description This allows the caller to specify the method to use to run a test - either to completion or
in a series of defined sections called partitions.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 201

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

bit_test_status

DataType Definition BitTestStatus

Description This specifies the status of the Bit call.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- getCbitResult.

11.5.1.2.5 CFM Resource Services

11.5.1.2.5.1 getCfmInfo

Purpose:

Gets the characteristics of the CFM.

Syntax:

CfmInfoReturnStatus getCfmInfo (
out CfmInfo cfm_info );
Description:

This service allows to get information about the identity and the properties of the CFM.

The list of information comprises the following attributes:

- CFM Id,

- CFM Resources,

- CFM Status,

- CFM Network Interfaces.

The value CFM_INFO_CALL_OK shall be returned by the service if it could return the requested CFM
information.

The value CFM_INFO_CALL_FAILED shall be returned by the service if it could not return the
requested CFM information.

Service call completes before calling process continues.

Parameter Description:

cfm_info

NATO UNCLASSIFIED 202

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition CfmInfo

Description CFM information.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None

11.5.1.2.5.2 getCfmStatus

Purpose:

Retrieves the status of the CFM.

Syntax:

CfmStatusReturnStatus getCfmStatus (
out CfmStatus cfm_status );
Description:

The value CFM_STATUS_CALL_OK shall be returned by the service if it could return the requested
CFM information.

The value CFM_STATUS_CALL_FAILED shall be returned by the service if it could not return the
requested CFM information.

Service call completes before calling process continues.

Parameter Description:

cfm_status

Data Type Definition CfmStatus

Description CFM status Description

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None

NATO UNCLASSIFIED 203

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.1.2.5.3 getMyPeId

Purpose:

Retrieves the ID of the PE on which this service is executed.

Syntax:

PeIdReturnStatus getMyPeId
out PublicId my_pe_id );
Description:

The value PE_ID_CALL_OK shall be returned by the service if it could return the requested PE Id.

The value PE_ID_CALL_FAILED shall be returned by the service if it could not return the requested
PE Id.

Service call completes before calling process continues.

Parameter Description:

my_pe_id

Data Type Definition PublicId

Description ID of the PE.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None

11.5.1.2.5.4 getPeInfo

Purpose:

Retrieves the PE info on which this service is executed.

Syntax:

PeInfoReturnStatus getPeInfo (
out PeResources my_resources );
Description:

The value PE_INFO_CALL_OK shall be returned by the service if it could return the requested PE
Info.

The value PE_INFO_CALL_FAILED shall be returned by the service if it could not return the
requested PE Info.

Service call completes before calling process continues.

NATO UNCLASSIFIED 204

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Parameter Description:

my_resources

Data Type Definition PeResources

Description Resources of the PE.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None

11.5.1.3 Communication Services

The MOS communication services (NII services) shall provide communications between modules or
internal to a module using the same services (i.e. no distinction of communications scope). The MOS
communication services are listed in Table 23. All of these services shall be available on every
module type.

Data types that are common to several MOS communication services are defined in section 8.2.

11.5.1.3.1 configureInterface

Purpose:

Configures an interface.

Syntax:

NiiReturnStatus configureInterface (
in PublicId interface_id ,
in NetworkDescriptor network_id ,
in InterfaceConfigurationData configuration_data );
Description:

The configureInterface service shall be used to configure an interface, which may be used for
any scope of communication (e.g. internal to a module or between modules). An interface can be
either a physical interface (e.g. ATM, FC) or a logical interface (NII). It assigns a network_id to an
interface_id. The possible range of interface_id values must be defined during system
design time. The service provides the MSL with necessary implementation specific configuration data
(e. g. physical device memory).

The configureInterface service uses the interface_id parameter to uniquely identify an

interface (IF) inside a CFM. The association between an interface_id value and an IF is
permanent and given by the specification of the module and/or the appropriate ASAAC standards. As
default information, the set of interface_id values used shall be the same in all modules of the
same type.

NATO UNCLASSIFIED 205

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The configureInterface service uses the network_id as a logical identifier for an interface.
The association between network_id and interface_id shall be one to one.

If the network_id is zero value than all associations from the given interface id to all network
ids will be destroyed. If the interface id is zero value, the association from the given
network_id to the interface id will be destroyed. Associations can be only destroyed if there
are no TC’s associated to a network_id involved. If the network_id has TC’s associated with it, then
the MOS_NII_OPEN_TC’S error will be flagged.

The value MOS_NII_ALREADY_CONFIGURED shall be returned by the service if it detects that the
user is attempting to repeat the configuration with the same network_id.

The association between a network_id and an interface_id remains until the

configureInterface service is called again with the same value for either network_id or
interface_id, which overwrites the association. If a new network_id value is associated with an
interface_id, then any network_id value previously associated with that interface_id
becomes invalid.

Calling the configureInterface service with a zero value for the interface_id may also invalidate a
network_id value.

The component network of the network_id should have the same value for a network at all
modules connected to that network, even though they may each use a different port component of
the network_id, and also a different interface_id to identify the relevant interface. Each
separately identified network in a system should have a unique value of the network component of
network_id.

The configuration_data parameter is a service user defined pointer to the configuration data that
is used by the MSL internally and to configure the interface.

The data_length shall indicate the length of the configuration_data in bytes.

During re-configuration, before a network_id can be associated with a new interface_id, calling
the destroyTransfer service shall have destroyed all TC’s associated with a network_id. The TC’s may
then be re-associated with the network_id afterwards, by calling the configureTransfer
service. If the configureInterface service is called with a network_id that still has TC’s
associated with it, the service shall return a MOS_NII_OPEN_TC’S error indicating this. The
getNetworkPortStatus service shall be used to obtain the network status and a list of the TC
identifiers for the TC’s that remain associated with the network_id. The value
MOS_NII_CALL_COMPLETE shall be returned by the service when the service has completed with no
errors.

The set of values valid for the interface_id is project dependent for any invalid value the service
shall return MOS_NII_INVALID_INTERFACE.

The value MOS_NII_CALL_FAILED shall be returned by the service when the service failed.

The value MOS_NII_INVALID_CONFIG shall be returned by the service if it detects any errors in the
configuration data.

The value MOS_NII_STORAGE_FAULT shall be returned by the service if it is unable to allocate the
buffer space required for the interface.

The value MOS_NII _OPEN_TCS shall be returned by the service if it is called for a network_id
that has TC's associated with it. The service getNetworkPortStatus can be used to obtain a list
of the TC identifiers for the TC’s that remain associated with the network_id.

NATO UNCLASSIFIED 206

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value MOS_NII_ALREADY_CONFIGURED shall be returned by the service if it detects that the
user is attempting to repeat the configuration with the same network_id.

If the call to the configureInterface service fails, no operation through this interface shall be
possible; i.e. this call shall successfully complete before any other communications service call
(except registerCallback) is made. Since otherwise, the network_id is not associated with an
interface_id.

This service call completes before the calling process continues.

Parameter Description:

interface_id

Data Type Definition PublicId

Description A unique value used to identify the local physical interface to be configured.

Domain Values No special values are associated with this parameter..

network_id

Data Type Definition NetworkDescriptor

Description A unique value used to identify the network to be configured.

Domain Values No special values are associated with this parameter..

configuration_data

Data Type Definition InterfaceConfigurationData

Description A structure containing the configuration data for the communications interface. The
content of the structure is implementation specific.

Domain Values No special values are associated with this parameter..

Prerequisite Conditions:

None

Associated Calls:

- configureTransfer,

- destroyTransfer,

- getNetworkPortStatus.

11.5.1.3.2 configureTransfer

Purpose:

Configures a TC (TC).

Syntax:

NATO UNCLASSIFIED 207

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NiiReturnStatus configureTransfer (
in PublicId tc_id ,
in NetworkDescriptor network_id ,
in TransferDirection send_receive ,
in TransferType message_streaming ,
in TC_ConfigurationData configuration_data ,
in Bool trigger_callback ,
in PublicId callback_id );
Description:

The configureTransfer service shall be used to configure the resources to provide information
required for the transmission or reception of information over a TC (TC). It assigns a TC identifier to a
TC and this to a network and port, identified by a network_id. In particular it describes the
direction of the transfer (whether send or receive), provides the communication configuration data.
The TC identifier is a defined parameter to be used by NII services to identify a TC. A TC is used
unidirectional connection between NII's. The TC identifier values for a TC should be the same at all
terminations. However, for initialisation, the TC identifiers used for a TC may be different at the
transmitter and the receiver(s).

The network_id is a parameter that has been defined by a configureInterface service and
shall have a valid association with an interface. The configuration data passed to the
configureTransfer service is network dependent and identified by the network_id.

A call to the configureTransfer service associates a TC identifier to a single network_id.

Multiple TC's may be associated with a single network_id, by multiple calls to the
configureTransfer service with the same network_id, but different TC identifiers.

The send_receive is a parameter that defines the direction of the communication on the TC.

The message_streaming parameter is used to differentiate between MESSAGE and STREAMING

transfers. MESSAGE transfers are initiated and require the use of sendTransfer and
receiveTransfer services.

Implementation Note: STREAMING transfers are automatic and data is written to or read from a
predefined buffer and transmitted or received whenever this buffer contains sufficient data, without the
need to call sendTransfer or receiveTransfer services. The descriptor of the STREAMING
data buffers shall be provided with the configuration_data parameter.

The configuration_data parameter is a service user defined pointer to the implementation

specific configuration data used by the service to configure the TC.

The trigger_callback is a user defined parameter that, if set to ASAAC_TRUE, shall cause the
service to indicate that a callback event shall be made for this TC. A COMMS_EV_BUFFER_SENT
callback event shall then occur when the sendTransfer service completes or a
COMMS_EV_BUFFER_RECEIVED callback event when data has arrived and the receiveTransfer
service should be called depending on the value of the send_receive parameter. If the
trigger_callback parameter is set to ASAAC_FALSE, no callback events are generated for this
TC.

The callback_id is used to identify the callback associated to the COMMS_EV_BUFFER_SENT or

COMMS_EV_BUFFER_RECEIVED event depending on the send_receive parameter.

The value MOS_NII_CALL_COMPLETE shall be returned by the service when it has completed with
no errors.

The value MOS_NII_CALL_FAILED shall be returned if the service failed.

NATO UNCLASSIFIED 208

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value MOS_NII_ALREADY_CONFIGURED shall be returned by the service if it detects that the
user is attempting to repeat the configuration of a TC without a destroyTransfer service in
between.

The value MOS_NII_INVALID_NETWORK shall be returned by the service if it detects that the
network_id value specified is not associated with a valid interface_id.

The value MOS_NII_INVALID_CONFIG shall be returned by the service if an error is detected in the
configuration data or if the address is out of the range of the service.

The value MOS_NII_INVALID_TC shall be returned in cases where ranges of TC numbers are used
to identify different service channels (like MLI or VC). This would avoid unnecessary polling with
receive transfer.

The value MOS_NII_STORAGE_FAULT shall be returned by the service if it is unable to allocate the
buffer space required for the interface.

This service call completes before the calling process continues.

Implementation note: If the TC needs special buffers (e.g. physical contiguous memory, special
memory area) for its internal operation, their descriptors may be provided with the
configuration_data parameter.

NOTE: Before a TC can be configured the communication network shall be configured at first using
the configureInterface service. This call shall be issued for each end of a TC, the sender and
receiver(s), before any transmission can take place over the TC.

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value to identify the transfer.

Domain Values No special values are associated with this parameter., implementation dependent.

network_id

Data Type Definition NetworkDescriptor

Description A unique value to identify the network.

Domain Values No special values are associated with this parameter.

send_receive

Data Type Definition TransferDirection

Description This defines the direction of data transfers on the TC.

Domain Values No special values are associated with this parameter., implementation dependent.

NATO UNCLASSIFIED 209

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

configuration_data

Data Type Definition TC_ConfigurationData

Description A structure containing the configuration data for the TC. The content of the structure
is implementation specific..

Domain Values No special values are associated with this parameter.

trigger_callback

Data Type Definition Boolean

Description ASAAC_TRUE causes the associated callback to be invoked when an event occurs
for this tc_id.

ASAAC_FALSE disables the callback activation for this tc_id.

Domain Values No special values are associated with this parameter., implementation dependent.

callback_id

Data Type Definition PublicId

Description Unique callback identifier used by the OS and the MSL. Set values shall be assigned
for specific functions to allow consistency across the system.

Domain Values 0..232-1

Prerequisite Conditions:

Before a TC can be configured, Associated Calls to configureInterface shall have been issued
for the network_id value specified.

This configureTransfer service call shall have been issued at each end of a TC, the transmitter
and the receiver(s), before a successful transfer can take place over the TC.

Associated Calls:

- destroyTransfer,

- sendTransfer,

- receiveTransfer.

11.5.1.3.3 sendTransfer

Purpose:

Sends data via a TC.

Syntax:

NiiReturnStatus sendTransfer (
in PublicId tc_id ,
in CharAddress transmit_data ,

NATO UNCLASSIFIED 210

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in Length data_length ,
in Time time_out );
Description:

The sendTransfer service shall be used to send a single block of data over an identified TC. The
information is passed via the buffer specified by the transmit_data parameter.

The sendTransfer service shall send the data transmit_data with the data length
data_length via the TC identified by parameter tc_id. The maximum value permitted for
data_length is network dependent. The time_out value shall be used to manage the return
behaviour of the service and is detailed below.

Implementation Note: Any header information added to the transmit_data by the

sendTransfer service needs to be removed by the receiveTransfer services. Any data required
to send the data should be passed (configuration_data) by the configureTransfer service to
the MSL.

The value MOS_NII_CALL_OK shall be returned when the service has been initiated with no errors.

The value MOS_NII_CALL_FAILED shall be returned by the service when the service failed.

The value MOS_NII_INVALID_TC shall be returned if the TC identifier is invalid.

The value MOS_NII_TC_NOT_CONFIGURED shall be returned if the TC is not configured.

The value MOS_NII_INVALID_MESSAGE_SIZE shall be returned if the message size is out of range.

The value MOS_NII_STORAGE_FAULT shall be returned if the required buffer space is not available.

If the time_out value is zero the service shall return immediately. If the time_out is not zero and if
no buffer is available for the TC, the service shall block for the specified time_out. If no buffer is
available before the time_out expires, it is considered as an error and the value
MOS_NII_CALL_FAILED shall be returned by the service.

Completion status may be returned through the callbackHandler associated with the
COMMS_EV_BUFFER_SENT event, if the callback is enabled and the trigger_callback parameter
was set in the configureTransfer service call for this TC. In this case, the timeout value is not
relevant and not used.

If no callback is enabled and a zero timeout is provided, the call returns immediately indicating the
send status.

If no callback is enabled and a non-zero timeout is provided, the service shall block the sending
thread until it can send the message or until the timeout expires.

Transfers occurring after consecutive calls to sendTransfer with the same TC identifier are
performed in sequence (first in, first out). However, no time order should be assumed between
transfers of data on different TC’s.

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value to identify the TC to be used for the transfer.

NATO UNCLASSIFIED 211

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values No special values are associated with this parameter., implementation dependent.

transmit_data

Data Type Definition CharAddress

Description The address of the data to be transmitted.

Domain Values No special values are associated with this parameter.

data_length

Data Type Definition Length

Description The length of the data to be transmitted in Bytes.

Domain Values No special values are associated with this parameter., implementation dependent.

time_out

Data Type Definition Time

Description Time out value for the service call.

Domain Values No special values are associated with this parameter., implementation dependent.

Prerequisite Conditions:

Before the data transfer can commence, a TC shall be configured using configureTransfer.

Associated Calls:

- receiveTransfer,

- configureTransfer,

- registerCallback,

- destroyTransfer.

11.5.1.3.4 receiveTransfer

Purpose:

Receives data from a TC.

Syntax:

NiiReturnStatus receiveTransfer (
in PublicId tc_id ,
inout CharAddress receive_data ,
in Length data_length_available ,
out Length data_length ,
in Time time_out );
Description:

NATO UNCLASSIFIED 212

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The receiveTransfer service shall be used to receive a single block of data from an identified TC.

If data has arrived on the identified TC, and has passed the appropriate consistency checks, the
receive_data pointer shall contain the address and the data_length shall contain the length of
the received data. If, however, the data fails the consistency checks, or contains any error detectable
by the MSL, the pointer shall be null and the error indicated in the NiiReturnStatus. The
time_out value shall be used to manage the return behaviour of the service and is detailed below.

The call may be instigated due to a callback, associated with the COMMS_EV_BUFFER_RECEIVED
event, if the callback is enabled and the trigger_callback parameter was set in the
configureTransfer service call for this TC, indicating information is available or through polling
until the information is available.

The NiiReturnStatus value MOS_NII_CALL_COMPLETE shall be returned if the service has

completed with no errors.

The NiiReturnStatus value MOS_NII_CALL_FAILED shall be returned if the service failed.

The NiiReturnStatus value MOS_NII_INVALID_TC shall be returned if the TC Identifier is invalid.

The NiiReturnStatus value MOS_NII_TC_NOT_CONFIGURED shall be returned if the TC is not

configured.

The NiiReturnStatus value MOS_NII_INVALID_MESSAGE_SIZE shall be returned if the

message size is out of range.

The NiiReturnStatus value MOS_NII_STORAGE_FAULT shall be returned if the required buffer

space is not available.

The NiiReturnStatus value MOS_NII_BUFFER_EMPTY shall be returned if there is no data

received for the TC since the last call to receiveTransfer or since the TC was configured by a call
to the configureTransfer service.

The NiiReturnStatus value MOS_NII_BUFFER_NOT_READY shall be returned if the received

message is incomplete.

If the time_out value is zero the service shall return immediately. If the time_out is not zero and if
no data is available, the service shall block for the specified time_out. If no data is available before
the time_out expires, the service shall return with the NiiReturnStatus value
MOS_NII_BUFFER_EMPTY.

If no callback is enabled and a zero timeout is provided, the call shall return immediately indicating the
status of the received data or an indication of no data availability. This supports a polling mode.

If no callback is enabled and a non-zero timeout is provided, the service shall block the receiving
thread until it receives a message or until the timeout expires. If the message is already available, it
returns immediately.

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value to identify the TC on which a message is going to be received.

Domain Values No special values are associated with this parameter., implementation

NATO UNCLASSIFIED 213

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

dependent.

receive_data

Data Type Definition CharAddress

Description The address of the buffer for the data to be received.

Domain Values No special values are associated with this parameter.

data_length_available

Data Type Definition Length

Description The avaiable data length on calling side in Bytes.

Domain Values No special values are associated with this parameter., implementation
dependent.

data_length

Data Type Definition Length

Description The actual data length of the message.

Domain Values No special values are associated with this parameter., implementation
dependent.

time_out

Data Type Definition Time

Description Time out value for the service call.

Domain Values No special values are associated with this parameter., implementation
dependent.

Prerequisite Conditions:

Before a call to receiveTransfer can be made, the TC shall have been configured using the
configureTransfer at the receiver.

Before a successful data transfer can commence, a TC shall be configured using

configureTransfer at each end of a connection, the transmitter and the receiver(s).

Associated Calls:

- sendTransfer,

- destroyTransfer,

- configureTransfer.

11.5.1.3.5 destroyTransfer

Purpose:

NATO UNCLASSIFIED 214

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Destroys a TC.

Syntax:

NiiReturnStatus destroyTransfer (
in PublicId tc_id ,
in NetworkDescriptor network_id );
Description:

The destroyTransfer service shall be used to release resources previously allocated to handle the
transmission or reception of information over a TC (TC). Following this service completion, the TC
shall no longer be operational.

This service destroys TC’s that were previously set up using the service configureTransfer. The
destruction of TC’s shall be performed inversely to the construction of the TC’s, e.g. if several
configureTransfer services were used for the set up, the same number of corresponding
destroyTransfer services shall be used.

The NiiReturnStatus value MOS_NII_CALL_COMPLETE shall be returned by the service if the

assigned TC has been successfully destroyed.

The NiiReturnStatus value MOS_NII_CALL_FAILED shall be returned by the service if the

assigned TC could not be successfully be destroyed.

The NiiReturnStatus value MOS_NII_INVALID_TC shall be returned by the service if the

assigned TC identifier is outside the range designated for this service.

The value MOS_NII_TC_NOT_CONFIGURED shall be returned by the service if a call is made with a
TC identifier that has not been associated with an interface for transmission by a successful call to the
configureTransfer service.

The NiiReturnStatus value MOS_NII_STORAGE_FAULT shall be returned by the service if it is

unable to allocate the buffer space required for this operation.

Service call completes before calling process continues.

If the user calls the destroyTransfer service, transfers already queued to be sent may be purged.

If the user calls the destroyTransfer service, transfers already received but not read by
receiveTransfer may be purged.

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value used to identify the transfer

Domain Values 0…232-1

network_id

Data Type Definition NetworkDescriptor

Description An identifier identifying, within the CFM, a particular physical interface to a particular

NATO UNCLASSIFIED 215

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Network.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

TC is configured.

Associated Calls:

- configureTransfer,

- This service configures a TC.

11.5.1.3.6 getNetworkPortStatus

Purpose:

Retrieves the network status.

Syntax:

NiiReturnStatus getNetworkPortStatus (
in NetworkDescriptor network_id ,
out NetworkPortStatus info_data );
Description:

The getNetworkPortStatus service shall be used to determine the status of a network port, as
available locally to the module. It shall be used in order to identify healthy resources.

The format of the info_data that is returned by the interface unit is network dependent. The
info_data structure shall include at least a list of TC identifiers that are associated with the
specified network_id.

The data_length parameter shall specify the length of the info_data in bytes.

The NiiReturnStatus value MOS_NII_STATUS_OK shall be returned if there were no errors

detected.

The NiiReturnStatus value MOS_NII_CALL_FAILED shall be returned if the call failed.

The NiiReturnStatus value MOS_NII_STATUS_ERROR shall be returned if an error has been

detected.

The NiiReturnStatus value MOS_NII_STATUS_INIT shall be returned if the network or interface

is in the process of initialising.

The NiiReturnStatus value MOS_NII_INVALID_NETWORK shall be returned if it detects that the

network_id value specified is not associated with a valid interface_id.

The NiiReturnStatus value MOS_NII_INVALID_MESSAGE_SIZE shall be returned if it detects

that the data to be returned is larger than the maximum data_length specified by data_length
value.

NATO UNCLASSIFIED 216

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

This service call returns (calling process continues) the getNetworkPortStatus information.
Notification that the requested data is available via the info_data is indicated through the callback
associated with the COMMS_EV_INFO, if the callbackHandler is registered and enabled.

Parameter Description:

info_data

Data Type Definition NetworkPortStatus

Description Status of the network port.

Domain Values Processor and network dependent.

network_id

Data Type Definition NetworkDescriptor

Description An identifier identifying, within the CFM, a particular physical interface to a particular
Network.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The network referenced has to be configured using configureInterface service.

Associated Calls:

- configureInterface.

11.5.1.3.7 receiveNetwork

Purpose:

Receives data from a network on any TC.

Syntax:

NiiReturnStatus receiveNetwork (
in NetworkDescriptor network ,
inout CharAddress receive_data ,
in Length data_length_available ,
out Length data_length ,
out PublicId tc_id ,
in Time time_out );
Description:

The receiveNetwork service shall be used to receive a single block of data on any TC allocated to
that network from an identified network.

If data has arrived on the identified network, and has passed the appropriate consistency checks, the
receive_data pointer shall contain the address, the data_length shall contain the length of the
received data and TC identifiers contain the TC Id of the received message.

NATO UNCLASSIFIED 217

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If, however, the data fails the consistency checks, or contains any error detectable by the MSL, the
pointer shall be null and the error indicated in the NiiReturnStatus. The time_out value shall be
used to manage the return behaviour of the service and is detailed below.

The call may be instigated due to a callback, associated with the COMMS_EV_BUFFER_RECEIVED
event, if the callback is enabled and the trigger_callback parameter was set in the
configureTransfer service call for this TC, indicating information is available or through polling
until the information is available.

The NiiReturnStatus value MOS_NII_CALL_COMPLETE shall be returned if the service has

completed with no errors.

The NiiReturnStatus value MOS_NII_CALL_FAILED shall be returned if the service failed.

The NiiReturnStatus value MOS_NII_INVALID_NETWORK shall be returned if the network is

invalid.

The NiiReturnStatus value MOS_NII_INVALID_MESSAGE_SIZE shall be returned if the

message size is out of range.

The NiiReturnStatus value MOS_NII_STORAGE_FAULT shall be returned if the required buffer

space is not available.

The NiiReturnStatus value MOS_NII_BUFFER_EMPTY shall be returned if there is no data

received for the network since the last call to receiveNetwork or since the network was configured
by a call to the configureInterface service.

The NiiReturnStatus value MOS_NII_BUFFER_NOT_READY shall be returned if the received

message is incomplete.

If the time_out value is zero the service shall return immediately. If the time_out is not zero and if
no data is available, the service shall block for the specified time_out. If no data is available before
the time_out expires, the service shall return with the NiiReturnStatus value
MOS_NII_BUFFER_EMPTY.

If no callback is enabled and a zero timeout is provided, the call shall return immediately indicating the
status of the received data or an indication of no data availability. This supports a polling mode.

If no callback is enabled and a non-zero timeout is provided, the service shall block the receiving
thread until it receives a message or until the timeout expires. If the message is already available, it
returns immediately.

Parameter Description:

network_id

Data Type Definition NetworkDescriptor

Description An identifier identifying, within the CFM, a particular physical interface to a particular
Network.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 218

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

receive_data

Data Type Definition CharAddress

Description The address of the buffer for the data to be received.

Domain Values No special values are associated with this parameter.

data_length_available

Data Type Definition Length

Description The avaiable data length on calling side in Bytes.

Domain Values No special values are associated with this parameter., implementation dependent.

data_length

Data Type Definition Length

Description The actual data length of the message.

Domain Values No special values are associated with this parameter., implementation dependent.

tc_id

Data Type Definition PublicId

Description A unique value to identify the TC on which the message has been received.

Domain Values No special values are associated with this parameter., implementation dependent.

time_out

Data Type Definition Time

Description Time out value for the service call.

Domain Values No special values are associated with this parameter., implementation dependent.

Prerequisite Conditions:

Before a call to receiveNetwork can be made, the TC shall have been configured using the
configureTransfer at the receiver.

Before a successful data transfer can commence, a network shall be configured using
configureInterface at each end of a connection, the transmitter and the receiver(s).

Associated Calls:

- sendTransfer,

- destroyTransfer,

- configureTransfer.

NATO UNCLASSIFIED 219

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.2 Specific Services

The Specific MOS services are grouped into the following categories,

- Services for the GPM,

- Services for the MMM, and

- Services for the PCM.

Table 24 lists the Specific MOS services defined in this section.

Table 24 – Specific Board MOS Services

Module MOS Services Description Section

Type

GPM None None None

PCM setPowerSwitch Turn a power switch on/off 11.5.2.2.

1

resetPowerSwitches Reset the power switch and switch all 11.5.2.2.

modules off. 2

getPowerSwitchStatus Return Status of a power switch 11.5.2.2.

3

MMM SetTxData Allows data to be copied to the MMM for 11.5.2.3.

storing. 1

SetRxData Allows data to be read from the MMM. 11.5.2.3.

2

StartTransfer Initiates the read or write of MMM data. 11.5.2.3.

3

SPM configureFragmentedTransfe 11.5.2.4.

r Configure a fragmented transfer
1

sendFragmentedTransfer 11.5.2.4.
Send a block of data on the given TC
2

receiveFragmentedTransfer Describe a regular set of data blocks where 11.5.2.4.

incoming information shall be put. 3

11.5.2.1 GPM Specific Services

On a GPM the MSL shall implement the AGL services are specified in 0.

11.5.2.2 PCM Specific Services

11.5.2.2.1 setPowerSwitch

Purpose:

NATO UNCLASSIFIED 220

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The setPowerSwitch function shall be used to switch power on/off to a module.

Syntax:

ReturnStatus setPowerSwitch (
in PublicId switch_id ,
in SwitchOp switch_op );
Description:

The service shall be used to request that a power switch is to be set to a specified state.

An ‘ERROR’ condition shall be returned if the request fails. Otherwise the return status shall be
‘SUCCESS’.

Parameter Description:

switch_id

Data Type Definition PublicId

Description Identifier for the relevant power switch

Domain Values No special values are associated with this parameter.

switch_op

Data Type Definition SwitchOp

Description Emuneration for the switch state

Domain Values All values of the enumerated type SwitchOp.

Prerequisite Conditions:

None

Associated Calls:

- resetPowerSwitches,

- getPowerSwitchStatus.

11.5.2.2.2 resetPowerSwitches

Purpose:

The resetPowerSwitches function shall be used to reset the power switch and to switch all
modules off.

Syntax:

ReturnStatus resetPowerSwitches ();

Description:

The service shall be used to request that all power switches on this CFM are to be reset to the OFF
state.

NATO UNCLASSIFIED 221

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

An ‘ERROR’ condition shall be returned if the request fails. Otherwise the return status shall be
‘SUCCESS’.

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

- setPowerSwitch

- getPowerSwitchStatus

11.5.2.2.3 getPowerSwitchStatus

Purpose:

The getPowerSwitchStatus function shall be used to get the current status of the power switch.

Syntax:

ReturnStatus getPowerSwitchStatus (
out PowerSwitch power_switch );
Description:

The service shall be used to inform the OS to request that all power switches on this CFM are to be
reset to the OFF state. The OS shall do this by means of resetPowerSwitches.

An ‘ERROR’ condition shall be returned if the request fails. Otherwise the return status shall be
‘SUCCESS’.

Parameter Description:

power_switch

Data Type Definition PowerSwitch

Description Structure including the switch_id and the SwitchStat structure.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- setPowerSwitch,

- resetPowerSwitches.

NATO UNCLASSIFIED 222

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.2.3 MMM Specific Services

The MMM specific services are associated with the management of device memory. They shall
include services in order to,

- Read device blocks,

- Write device blocks,

- Erase device memory,

- Get device status.

11.5.2.3.1 SetTxData

Purpose:

Allows data to be copied to the MMM for storing.

Syntax:

MslStatus SetTxData (
out unsigned long key ,
in Address buffer ,
in unsigned long size );
Description:

This service sets up a write to the memory device. A unique key is returned from the call allowing
identification of the data transfer.

If the read is successful the value MSL_OK is returned.

If a hardware fault prevents writing the data, the value MSL_IO_FAILED is returned.

If the data cannot be written because the disk is busy, the value MSL_IO_BUSY is returned.

If the write fails for any other reason the value MSL_INVALID_CALL is returned.

Parameter Description:

key

Data Type Definition unsigned long

Description A unique identifier for the transfer.

Domain Values ≤ 232-1

buffer

Data Type Definition Address

Description The address of the buffer that contains the data.

Domain Values 0 ≤ RegionID ≤ 232-1

NATO UNCLASSIFIED 223

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

size

Data Type Definition unsigned long

Description Size of data in bytes to be written

Domain Values ≤ 232-1

Prerequisite Conditions:

None

Associated Calls:

- createRegion,

- attach,

- detach,

- destroyRegion.

11.5.2.3.2 SetRxData

Purpose:

Allows data to be read from the MMM

Syntax:

MslStatus SetRxData (
out unsigned long key ,
in Address buffer ,
in unsigned long size );
Description:

This service sets up a read from the memory device. A unique key is returned from the call allowing
identification of the data transfer.

If the read is successful the value MSL_OK is returned.

If a hardware fault prevents reading the data, the value MSL_IO_FAILED is returned.

If the data cannot be read because the disk is busy, the value MSL_IO_BUSY is returned.

If the read fails for any other reason the value MSL_INVALID_CALL is returned.

Parameter Description:

key

Data Type Definition unsigned long

Description A unique identifier for the transfer.

NATO UNCLASSIFIED 224

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values ≤ 232-1

buffer

Data Type Definition Address

Description The address of the buffer that contains the data.

Domain Values 0 ≤ RegionID ≤ 232-1

size

Data Type Definition unsigned long

Description Size of data in bytes to be read

Domain Values ≤ 232-1

Prerequisite Conditions:

None

Associated Calls:

- createRegion,

- attach,

- detach,

- destroyRegion.

11.5.2.3.3 StartTransfer

Purpose:

Initiates the read or write of MMM data set up by the SetRxData and SetTxData services

Syntax:

MslStatus StartTransfer (
in unsigned long key ,
in unsigned long lba ,
in IOoperation op )
Description:

Used after the SetRxData and SetTxData services, this service initiates the transfer that has been set
up by the initial service. The key allows identification of the data transfer.

This service is non-blocking and it is associated with a callback event ‘MMM_SD_EVENT’ (see
section 11.5.1.2.3.5), which indicates the end of the transfer to MMM storage.

If the transfer is successful, the value MSL_OK is returned.

If a transfer fails because of a hardware fault, the value MSL_IO_FAILED is returned.

NATO UNCLASSIFIED 225

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If the transfer fails because the disk is busy, the value MSL_IO_BUSY is returned.

If the transfer fails for any other reason, the value MSL_INVALID_CALL is returned.

Parameter Description:

key

Data Type Definition unsigned long

Description A unique identifier for the transfer.

Domain Values ≤ 232-1

lba

Data Type Definition unsigned long

Description Logical Block Address used to access the disk.

Domain Values ≤ 232-1

op

Data Type Definition IOoperation

Description Specifies the type of operation to be performed on the memory device

Domain Values 0x0B000000 ≤ IOoperation ≤ 0x0B000004

Prerequisite Conditions:

None

Associated Calls:

- SetRxData,

- SetTxData.

11.5.2.4 SPM Specific Services

11.5.2.4.1 configureFragmentedTransfer

Purpose:

Configures a fragmented transfer.

This service call completes before the calling process continues.

Syntax:

NiiReturnStatus configureFragmentedTransfer (
in PublicId tc_id ,
in NetworkDescriptor network_id ,

NATO UNCLASSIFIED 226

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in TransferDirection send_receive ,
in TransferType message_streaming ,
in TC_ConfigurationData configuration_data ,
in Bool trigger_callback ,
in PublicId callback_id );
Description:

The configureFragmentedTransfer service is part of the NII extension for Signal Processing.

It shall be used to configure resources to provide information required for the fragmented transmission
or reception of information over a TC (TC). It assigns a TC identifier to a TC and this to a network and
port, identified by a network_id. In particular it describes the direction of the transfer (whether send
or receive), provides the network buffer distribution and collection laws.

The TC identifier is a service user defined parameter for use by the other NII services that identifies a
TC. A TC is used for the unidirectional transfer of data between the NII local to the service user and
one or more NII's, i.e. for communication internal and external to the module.

The configureFragmentedTransfer service users at the terminations of the TC define the TC

identifier values for a TC separately. The TC identifiers values for a TC should be the same at all
terminations at MOS level.

The network_id is a parameter that has been defined by a configureInterface service user
and has a valid association with an interface_id.

A call to the configureFragmentedTransfer service associates a TC identifier to a single

network_id. Multiple TC's may be associated with a single network_id at both the transmitters
and the receivers, by multiple calls to the configureFragmentedTransfer service with the same
network_id, but different TC identifiers. A TC may be associated with multiple networks, but only at
the transmitter side. Again, calling the configureFragmentedTransfer service multiple times,
each with the same TC identifiers but different network identifiers does this. Where a TC is associated
with multiple networks, a call to the sendFragmentedTransfer service shall cause the data passed
to that service to be transmitted through all the interfaces that are associated with the multiple
network identifiers.

The send_receive is a service user defined parameter that defines the direction of the
communication on the TC. Only one call to this service can be made per TC with the send_receive
parameter set to RECEIVE, without the destroyTransfer being called to destroy the TC. A TC may
be associated with multiple networks, if the send_receive parameter is set to SEND for the calls to
the configureTransfer service for these associations.

The message_streaming parameter shall be set to the value MESSAGE in all cases.

The configuration_data parameter is a service user defined pointer to the implementation

specific configuration data used by the service to configure the TC. The parameter
configuration_data contains specific network dependent addressing and network buffer
distribution and collection laws stored by the MSL for use by the sendFragmentedTransfer and
receiveFragmentedTransfer services.

The trigger_callback is a user defined parameter that, if set to TRUE, shall cause the service to
indicate that a callback event shall be made for this TC. A COMMS_EV_BUFFER_SENT callback event
shall then occur when the sendFragmentedTransfer service completes or a
COMMS_EV_BUFFER_RECEIVED callback event when data has arrived and the
receiveFragmentedTransfer service should be called depending on the value of the
send_receive parameter. If the trigger_callback parameter is set to FALSE, no callback
events are generated for this TC.

NATO UNCLASSIFIED 227

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The callback_id shall be used to identify the callback associated to the COMMS_EV_BUFFER_SENT
or COMMS_EV_BUFFER_RECEIVED event depending on the send_receive parameter.

The NiiReturnStatus value MOS_NII_COMPLETE shall be returned by the service when it has
completed with no errors.

The NiiReturnStatus value MOS_NII_ALREADY_CONFIGURED shall be returned by the service if

it detects that the user is attempting to repeat the configuration of a receive TC, i.e. the
send_receive parameter is set to RECEIVE.

The NiiReturnStatus value MOS_NII_INVALID_NETWORK shall be returned by the service if it

detects that the network_id value specified is not associated with a valid interface_id.

The NiiReturnStatus value MOS_NII_INVALID_CONFIG shall be returned by the service if an

error is detected in the configuration data or if the address is out of the range of the service.

The NiiReturnStatus value MOS_NII_STORAGE_FAULT shall be returned by the service if it is

unable to allocate the buffer space required for the interface.

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value used to identify the transfer

Domain Values 0…232-1

network_id

Data Type Definition NetworkDescriptor

Description An identifier identifying, within the CFM, a particular physical interface to a particular
Network.

Domain Values No special values are associated with this parameter.

send_receive

Data Type Definition TransferDirection

Description This defines the direction of data transfers on the TC, (as viewed from the site calling
configureTransfer).

Domain Values { SEND, RECEIVE }

configuration_data

Data Type Definition TC_ConfigurationData

Description Address of a structure containing the configuration data for the TC. The format and
content of the structure is network specific. Appropriate memory buffer descriptors
needed for the TC configuration and operation will be provided through this structure.

This configuration data shall be used to provide the network buffer distribution and

NATO UNCLASSIFIED 228

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

collection laws.

Domain Values Processor and network dependent.

trigger_callback

Data Type Definition Boolean

Description TRUE causes the associated callback to be invoked when an event occurs for this
tc_id.

FALSE disables the callback activation for this tc_id.

Domain Values { TRUE, FALSE }

callback_id

Data Type Definition PublicId

Description Unique callback identifier used by the OS and the MSL. Set values shall be assigned
for specific functions to allow consistency across the system.

Domain Values 0..232-1

Prerequisite Conditions:

Important: Before a TC can be configured. Associated Calls to configureInterface shall have

been issued for the network_id value specified.

This configureFragmentedTransfer service call shall have been issued at each end of a TC, the
transmitter and the receiver(s), before a successful transfer can take place over the TC.

Associated Calls:

- configureInterface,

- destroyTransfer,

- sendFragmentedTransfer,

- receiveFragmentedTransfer.

11.5.2.4.2 sendFragmentedTransfer

Purpose:

Sends data via a fragmented TC.

Syntax:

NiiReturnStatus sendFragmentedTransfer (
in PublicId tc_id ,
in CharAddress transmit_data ,
in Length data_length );
Description:

NATO UNCLASSIFIED 229

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The service sendFragmentedTransfer is an extension of the NII to support some communication

mechanisms that are specific to some Signal Processing applications.

It shall be used to initiate a communication to fragment and pass a single block of data over an
identified TC. The information shall be passed via the buffer specified by the transmit_data parameter.

The sendFragmentedTransfer service shall use the TC identifier to identify the TC; the specific
buffer addressing and fragmentation law, passed to the MSL through the
configureFragmentedTransfer service calls; and the set of interface identifiers associated with
the TC.

The sendFragmentedTransfer service transfers the transmit_data with the length

data_length on the identified TC. A call to the sendFragmentedTransfer service shall cause the
data to be transmitted through all interfaces associated with the TC. The maximum value permitted for
data_length is network dependent.

Any identifier, check value or addressing data that is added to the transmit_data by the
sendFragmentedTransfer service shall be removed by the receiveFragmentedTransfer
services. Any values that are required to be the known in advance at the receiving ends of the TC
shall be provided through the configureFragmentedTransfer service in the
configuration_data. The tc_id, network identifier and interface identifier parameters may be
different at both ends of the TC (refer to initialisation section).

The intent of the call is shown in 9.5.6.3. The first block to be sent is indicated by transmit_data.
Having sent block_length bytes, the initial address is incremented by step and another block sent.
Data between the blocks identified are sent on different TC’s (e.g. starting at transmit_data +
block_length).

The value MOS_NII_CALL_OK shall be returned by the service when the service has been initiated
with no errors.

The value MOS_NII_INVALID_TC shall be returned by the service if a tc_id outside the range
designated for this service is detected.

The value MOS_NII_TC_NOT_CONFIGURED shall be returned by the service if a call is made with a
tc_id that has not been associated with an interface for transmission by a successful call to the
configureFragmentedTransfer service.

The value MOS_NII_INVALID_MESSAGE_SIZE shall be returned by the service if a message size

that is outside the range valid for the TC and network type is detected.

The value MOS_NII_INVALID_CONFIG shall be returned by the service if an error is detected in the
configuration data or if the address is out of the range of the service.

The value MOS_NII_STORAGE_FAULT shall be returned by the service if it is unable to allocate the
buffer space required for the interface.

This service call returns (calling process continues) before completion of the action. Completion
status may be returned through the callback associated with the COMMS_EV_BUFFER_SENT event, if
the callback is enabled and the trigger_callback parameter was set in the
configureFragmentedTransfer service call for this TC.

Transfers occurring after consecutive calls to sendFragmentedTransfer with the same tc_id are
performed in sequence (first in, first out). However, no time order should be assumed between
transfers of data on different TC’s.

If the user calls the destroyTransfer service, transfers queued by consecutive calls to
sendFragmentedTransfer shall be purged.

NATO UNCLASSIFIED 230

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

network internal
transmit_data
view of data
transferred
step

data_length

block_length

Figure 52 - sendFragmentedTransfer Data Buffer Description

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value used to identify the transfer

Domain Values 0…232-1

transmit_data

Data Type Definition CharAddress

Description Address of a message buffer containing the message data

Domain Values 0…232-1

data_length

Data Type Definition Length

Description The actual data length of the message.

Domain Values No special values are associated with this parameter., implementation dependent.

Prerequisite Conditions:

Before a call to the sendFragmentedTransfer service can be made, the TC shall have been
configured using configureFragmentedTransfer service at the sender.

Before successful data transfer can commence, a TC shall have been configured using
configureFragmentedTransfer at each end of a connection, the transmitter and the receiver(s).

NATO UNCLASSIFIED 231

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- receiveFragmentedTransfer,

- configureFragmentedTransfer,

- registerCallback,

- destroyTransfer.

11.5.2.4.3 receiveFragmentedTransfer

Purpose:

If the user calls the destroyTransfer service, transfers received but not read by calls to
receiveFragmentedTransfer shall be purged.

This service call completes before the calling process continues.

Syntax:

NiiReturnStatus receiveFragmentedTransfer (
in PublicId tc_id ,
inout CharAddress receive_data ,
out Length data_length_available ,
in Length data_length );
Description:

The receiveFragmentedTransfer service is an extension of the NII to support some

communications mechanisms that are specific to some Signal Processing applications.

It shall collect information received from the network. The call shall be instigated due to a callback,
associated with the COMMS_EV_BUFFER_RECEIVED event, if the callback is enabled and the
trigger_callback parameter was set in the configureFragmentedTransfer service call for
this TC, indicating information is available or through polling until the information is available.

The receiveFragmentedTransfer service shall use the tc_id to identify the TC; the specific
buffer addressing and network collection law parameters, passed to the MSL through the
configureFragmentedTransfer service call; and the interface_id associated with the TC.

If data has arrived on the identified TC, and has passed the appropriate consistency checks, the
receive_data pointer shall contain the address and the data_length shall contain the length of
the received data. If, however, the data fails the consistency checks, or contains any error detectable
by the MSL, the pointer shall be NULL and the error indicated in the NiiReturnStatus.

The value MOS_NII_CALL_COMPLETE shall be returned by the service when the service has
completed with no errors.

The value MOS_NII_INVALID_TC shall be returned by the service if a tc_id outside the range
designated for this service is detected.

The value MOS_NII_TC_NOT_CONFIGURED shall be returned by the service if a call is made with a
tc_id that has not been associated with an interface for transmission by a successful call to the
configureFragmentedTransfer service.

The value MOS_NII_INVALID_MESSAGE_SIZE shall be returned by the service if a message size

that is outside the range valid for the TC is detected.

NATO UNCLASSIFIED 232

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value MOS_NII_BUFFER_EMPTY shall be returned by the service if there is no data received for
the TC since the last call to receiveFragmentedTransfer or since the TC was configured by a
call to the configureFragmentedTransfer service.

The value MOS_NII_BUFFER_NOT_READY shall be returned by the service if the received message is
incomplete.

The value MOS_NII_STORAGE_FAULT shall be returned by the service if it is unable to allocate the
buffer space required for the interface.

Both Figure 53 and Figure 54 show the splitting of incoming data and fragmentation.

network internal
receive_data
view of arriving
data
step

data_length

block_length

Figure 53 - Splitting of Incoming Data with receiveFragmentedTransfer

300
400 300

100

300
200
400
200
300

100

300 300
400

sending 3 blocks of 400 bytes received into 4 blocks of 300 bytes

Figure 54 - Different Step Sizes with Fragmented Transfers

NATO UNCLASSIFIED 233

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Parameter Description:

tc_id

Data Type Definition PublicId

Description A unique value used to identify the transfer

Domain Values 0…232-1

receive_data

Data Type Definition CharAddress

Description Input: The address of a new buffer to be used by the MSL.

Output: The address of the buffer that contains the requested data. If no valid data is
available, the MSL shall set this parameter to a NULL value.

Domain Values 0…232-1

data_length_available

Data Type Definition Length

Description The available data length for a message on calling side.

Domain Values No special values are associated with this parameter., implementation dependent.

data_length

Data Type Definition Length

Description The actual data length of the message.

Domain Values No special values are associated with this parameter., implementation dependent.

Prerequisite Conditions:

Before a call to receiveFragmentedTransfer can be made, the TC shall have been configured
using the configureFragmentedTransfer at the receiver.

Before a successful data transfer can commence, a TC shall be configured using

configureFragmentedTransfer at each end of a connection, the transmitter and the receiver(s).

Associated Calls:

- sendFragmentedTransfer,

- destroyTransfer,

- configureFragmentedTransfer.

NATO UNCLASSIFIED 234

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.3 MOS Bespoke Extension Services

The MOS Bespoke Extension services shall provide access to the on-module resources that are
required in a bespoke OS approach to control the processor and its resources. These services, as
listed below, shall be available on every module type where a bespoke OS is used.

Table 25 - MOS Bespoke Extension Services

Service Type Bespoke Extension Services Description Section

Context createContext Creates a processor context to associate with 11.5.3.1.

Services a virtual memory area. 1

deleteContext 11.5.3.1.
Deletes a processor context.
2

switchContext Used by the OS to get the MSL to switch 11.5.3.1.

control between two processor contexts. 3

enterCriticalSection Enter a critical section and therefore disable 11.5.3.1.

interrupts. 4

leaveCriticalSection Leave a critical section and therefore enable 11.5.3.1.

interrupts. 5

addSEP Add a service entry point for a service 11.5.3.1.

provided by a virtual memory area. 6

VM Services createVM Create a virtual memory area to associate 11.5.3.2.

with a process. 1

deleteVM 11.5.3.2.
Delete a virtual memory area.
2

getMyVM Find out the virtual memory identifier 11.5.3.2.

associated with the calling process. 3

Copy a block of memory from source virtual

copyMemory 11.5.3.2.
memory area to a destination virtual memory
4
area.

Region createRegion Create a memory region to be attached to a 11.5.3.3.

Services virtual memory area. 1

deleteRegion 11.5.3.3.
Delete a memory region.
2

attach Attach a memory region to a virtual memory 11.5.3.3.

area. 3

attachAt Attach a memory region to a virtual memory 11.5.3.3.

area at a specified address. 4

detach Detach a memory region from a virtual 11.5.3.3.

memory area. 5

NATO UNCLASSIFIED 235

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.3.1 Context Services

11.5.3.1.1 createContext

Purpose:

Creates a processor context to associate with a virtual memory area.

Syntax:

MslStatus createContext (
in PublicId vmid ,
in PublicId stack ,
in Address entry ,
out PublicId cpu_context );
Description:

This service shall allow the MSL to create a mapping between a virtual memory area and a CPU
context identifier that the caller will use to indicate the context to be executed. This processor context
is associated to the virtual memory area specified by the vmid parameter. The stack parameter is
used to define the stack start point to the MSL. The logical address of the entry point of the process in
the virtual memory area is given by entry. The context ID of the created context is returned in
cpu_context.

The value MSL_OK shall be returned by the service if it could create a context and return a valid
context ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
region ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
logical address for entry.

The value MSL_FAILED shall be returned by the service if it could not create a context for any other
reason.

Parameter Description:

vmid

Data Type Definition PublicId

Description The identifier of the virtual memory area in which the context will run.

Domain Values No limitation for this service.

stack

Data Type Definition PublicId

Description The identifier of the region that the created context will utilise for its stack.

Domain Values No limitation for this service.

NATO UNCLASSIFIED 236

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

entry

Data Type Definition Address

Description The logical address within the created context’s virtual memory area at which
execution will begin.

Domain Values No special values are associated with this parameter.

cpu_context

Data Type Definition PublicId

Description Identifies the created context.

Domain Values No limitation for this service.

Prerequisite Conditions:

Before this service can use a virtual memory area, the createVM service must be used to create it.

Associated Calls:

- deleteContext,

- switchContext.

11.5.3.1.2 deleteContext

Purpose:

Deletes a processor context associated with a virtual memory area.

Syntax:

MslStatus deleteContext (
in PublicId cpu_context );
Description:

This service shall delete a processor context, specified by the cpu_context parameter.

The value MSL_OK shall be returned by the service if it could delete a context.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
cpu_context.

The value MSL_FAILED shall be returned by the service if it could not delete a context for any other
reason.

Parameter Description:

cpu_context

Data Type Definition PublicId

NATO UNCLASSIFIED 237

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Identifies the context to be deleted

Domain Values No limitation for this service.

Prerequisite Conditions:

Before a context can be deleted, it must have already been created using the createContext service.

Associated Calls:

- createContext,

- switchContext.

11.5.3.1.3 switchContext

Purpose:

Used by the OS to get the MSL to switch control between two processor contexts.

Syntax:

MslStatus switchContext (
in PublicId cpu_context );
Description:

This service shall allow the caller to switch to a particular process thread, identified by cpu_context,
for execution. In normal conditions, this service does not return an MslStatus value. The service
switchContext() only returns if it fails

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
cpu_context.

The value MSL_FAILED shall be returned by the service if it could not switch to a context for any
other reason.

Parameter Description:

cpu_context

Data Type Definition PublicId

Description The ID of the context to be run next, as produced by a call to createContext().

Domain Values No limitation for this service.

Prerequisite Conditions:

Before a context can be used in the switchContext service, it must have already been created using
the createContext service.

Associated Calls:

- createContext,

- deleteContext.

NATO UNCLASSIFIED 238

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.3.1.4 enterCriticalSection

Purpose:

Enter a critical section of the code.

Syntax:

MslStatus enterCriticalSection();
Description:

This service informs the MSL that the caller is now in a critical section and that callbacks shall be
disabled.

The value MSL_OK shall be returned by the service if it is successful.

The value MSL_FAILED shall be returned by the service if it is not successful.

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

- leaveCriticalSection.

11.5.3.1.5 leaveCriticalSection

Purpose:

Leave a critical section of the code.

Syntax:

MslStatus leaveCriticalSection();
Description:

This service informs the MSL that the caller is now leaving a critical section and that callbacks shall
be enabled.

The value MSL_OK shall be returned by the service if it is successful.

The value MSL_FAILED shall be returned by the service if it is not successful.

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

NATO UNCLASSIFIED 239

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- enterCriticalSection.

11.5.3.1.6 addSEP

Purpose:

This service registers the entry point of a service provided by a virtual memory area.

Syntax:

MslStatus addSEP(
in unsigned long service_id ,
in PublicId service_vm ,
in Address entry );
Description:

This service shall add a service entry point for a service provided by a virtual memory area to the
MSL’s list of entry points. This is a list of services, their entry point, and the virtual memory area that
provides the service. A service entry point is a logical address in a virtual memory area where the
executable code of the service begins. When a service in one virtual memory area is called from
another virtual memory area, the MSL uses the service entry point to invoke the service.

The value MSL_OK shall be returned by the service if it could successfully add the entry point.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
service_vm.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
logical address for entry.

The value MSL_FAILED shall be returned by the service if the operation fails.

Parameter Description:

service_id

Data Type Definition unsigned long

Description A unique number that will be used to identify the service whenever it is called. Note
that the same space is used for MSL services and OS services.

Domain Values service_id >= 0x0 < 0x7F: Reserved for MSL use
service_id > 0x7F : Available for OSL use

service_vm

Data Type Definition PublicId

Description The identifier of the virtual memory area to provide the service.

Domain Values No limitation for this service.

entry

Data Type Definition Address

NATO UNCLASSIFIED 240

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The logical address within the virtual memory area of the entry point of the service.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

Before service can be registered for a virtual memory area, the virtual memory area must be created
using the createVM service.

Associated Calls:

None

11.5.3.2 VM Services

11.5.3.2.1 createVM

Purpose:

Create a virtual memory area to associate with the code and data of a process.

Syntax:

MslStatus createVM (
in PublicId code ,
in Address code_addr ,
in PublicId data ,
in Address data_addr ,
out PublicId vm );
Description:

Initialises data structures inside the MSL so that they represent a virtual memory area. Specified code
and data regions are attached to this virtual memory area during the creation. Calling the
createRegion service prior to calling createVM must have created these regions before. The logical
address in virtual memory space at which each type of region is attached is then specified by its
associated Address parameter. Any additional regions are then created using createRegion and
attached using attach.

The value MSL_OK shall be returned by the service if it could successfully create the virtual memory
area.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
logical address for code_addr or data_addr.

The value MSL_FAILED shall be returned by the service if the create operation fails.

Parameter Description:

code

Data Type Definition PublicId

Description The unique identification number for the code region to be attached to the virtual
memory area, as produced by calling the createRegion service.

NATO UNCLASSIFIED 241

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values No limitation for this service.

code_addr

Data Type Definition Address

Description Address in the virtual memory area’s logical address space at which the code region
is to be attached.

Domain Values No special values are associated with this parameter.

data

Data Type Definition PublicId

Description The unique identification number for the data region to be attached to the virtual
memory area, as produced by calling the createRegion service.

Domain Values No limitation for this service.

data_addr

Data Type Definition Address

Description Address in the virtual memory area’s logical address space at which the data region
is to be attached.

Domain Values No special values are associated with this parameter.

vm

Data Type Definition PublicId

Description Returns a unique identifier for the virtual memory area created, to be used in
subsequent service calls to identify this virtual memory area.

Domain Values No limitation for this service.

Prerequisite Conditions:

None

Associated Calls:

- deleteVM,

- getMyVM.

11.5.3.2.2 deleteVM

Purpose:

Delete a virtual memory area.

Syntax:

NATO UNCLASSIFIED 242

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MslStatus deleteVM (
in PublicId vmid );
Description:

Returns a virtual memory area to an initial, inactive state provided that no regions are currently
attached to it. This means that all regions, including code and data, must be explicitly detached before
the deleteVM can be called successfully.

The value MSL_OK shall be returned by the service if the virtual memory area was deleted
successfully.

The value MSL_FAILED shall be returned if there is at least one region still attached to the virtual
memory area.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

Parameter Description:

vmid

Data Type Definition PublicId

Description A unique identifier for the virtual memory area to be deleted, as obtained by creating
the virtual memory area using the createVM service.

Domain Values No limitation for this service.

Prerequisite Conditions:

Before the virtual memory area can be deleted, the virtual memory area must already have been
created using the createVM service.

Associated Calls:

- createVM,

- getMyVM.

11.5.3.2.3 getMyVM

Purpose:

Find out the virtual memory identifier associated with the calling process.

Syntax:

MslStatus getMyVM (
out PublicId result );
Description:

This service returns to the caller the virtual memory identifier associated with the calling process.

The value MSL_OK shall be returned by the service if it is successful.

Parameter Description:

NATO UNCLASSIFIED 243

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

vmid

Data Type Definition PublicId

Description The unique identifier for the virtual memory area.

Domain Values No limitation for this service.

Prerequisite Conditions:

None

Associated Calls:

- createVM,

- deleteVM.

11.5.3.2.4 copyMemory

Purpose:

Copy a block of memory from the source to the destination.

Syntax:

MslStatus copyMemory (
in PublicId source_vm_id ,
in Address source_address ,
in PublicId destination_vm_id ,
in Address destination_address ,
in unsigned long size );
Description:

This service copies a block of memory from the source to the destination. The source and destination
address is a logical address applicable to the relevant virtual address space.

The value MSL_OK shall be returned by the service if the copy was successful.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
logical address.

Parameter Description:

source_vm_id

Data Type Definition PublicId

Description The logical identifier for the virtual memory area from which the block shall be copied.

Domain Values No limitation for this service.

NATO UNCLASSIFIED 244

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

source_address

Data Type Definition Address

Description The logical address within the virtual memory area from which the block shall be
copied.

Domain Values No special values are associated with this parameter.

destination_vm_id

Data Type Definition PublicId

Description The logical identifier for the virtual memory area to which the block shall be copied.

Domain Values No limitation for this service.

destination_address

Data Type Definition Address

Description The logical address within the virtual memory area to which the block shall be copied.

Domain Values No special values are associated with this parameter.

size

Data Type Definition unsigned long

Description The number of bytes to be copied.

Domain Values No limitation for this service.

Prerequisite Conditions:

Before this service can be used, both source and destination virtual memory areas must be created
using the createVM service.

Associated Calls:

- createVM,

- deleteVM.

11.5.3.3 Region Services

11.5.3.3.1 createRegion

Purpose:

Create a memory region to be attached to a virtual memory area.

Syntax:

MslStatus createRegion (

NATO UNCLASSIFIED 245

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in PoolType pool ,
in unsigned long num_pages ,
out PublicId region );
Description:

Reserves an unallocated area of physical memory for later use by virtual memory areas.

This memory can be obtained from one of several pools of physical memory:

The CODE_RAM, DATA_RAM or STACK_RAM pools which all reside in RAM.

The BUFFER pool – intended to create regions that will be attached to more than one virtual memory
area as shared memory,

The STREAM_BUFFER pool – a pool of buffers used for streaming.

The value MSL_OK shall be returned by the service if the region was created successfully.

The value MSL_FAILED shall be returned if the service for any reason was unable to create the
region.

Parameter Description:

pool

Data Type Definition PoolType

Description Selects to pool from which memory is obtained.

Domain Values CODE_RAM,

DATA_RAM,
STACK_RAM,
BUFFER,
STREAM_BUFFER.

num_pages

Data Type Definition unsigned long

Description The number of pages in physical memory to be used to form the region.

Domain Values No limitation for this service.

region

Data Type Definition PublicId

Description The variable region will be altered to contain a unique identification number for the
region just created, for use in subsequent service calls needing to refer to the region.

Domain Values No limitation for this service.

Prerequisite Conditions:

None

Associated Calls:

NATO UNCLASSIFIED 246

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- deleteRegion,

- attach,

- attachAt,

- detach.

11.5.3.3.2 deleteRegion

Purpose:

Delete a memory region.

Syntax:

MslStatus deleteRegion(
in PublicId reg );
Description:

Deletes a region from physical memory, making this memory available to be re-allocated to new
regions if so desired. Note that a region must not be attached to any virtual memory areas for it to be
deleted successfully. The number of virtual memory areas to which the region is attached will be
checked by this service. This can be greater than one for Buffer regions, which act as shared
memory. It is thus necessary to detach the region to be deleted by calling the detach service for each
associated virtual memory area prior to using deleteRegion.

The value MSL_OK shall be returned by the service if the region was deleted successfully.

The value MSL_FAILED shall be returned if the region is still attached to a virtual memory area.

The value MSL_INVALID_PARAMETER shall be returned if the region specified does not exist.

Parameter Description:

reg

Data Type Definition PublicId

Description A unique identifier for the region to be deleted, as obtained by creating the region
with the createRegion service

Domain Values No limitation for this service.

Prerequisite Conditions:

Before a region can be deleted, the region must be detached from all virtual memory areas by calling
the detach service for each associated virtual memory area.

Associated Calls:

- createRegion,

- attach,

- attachAt,

NATO UNCLASSIFIED 247

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- detach.

11.5.3.3.3 attach

Purpose:

Attach a memory region to a virtual memory area.

Syntax:

MslStatus attach(
in PublicId reg ,
in PublicId dest_vm ,
in MemoryUsage usage ,
out Address attached_here );
Description:

This service makes the specified virtual memory area (dest_vm) aware of the region (reg) by updating
its internal tables to give the virtual memory area access to the physical memory associated with reg.
This access is limited to being either READ_ONLY or READ_WRITE according to the value of the
usage parameter. The service determines where to attach the region in the virtual memory area’s
address space and returns this attachment logical address to the caller in attached_here.

The value MSL_OK shall be returned by the service if the region was attached successfully.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
Region ID.

Parameter Description:

reg

Data Type Definition PublicId

Description The identification number of the region to be attached, obtained by creating the
region using the createRegion service.

Domain Values No limitation for this service.

dest_vm

Data Type Definition PublicId

Description The identification number of the virtual memory area to which attachment is to occur,
as obtained by creating the virtual memory area using the createVM service.

Domain Values No limitation for this service.

usage

Data Type Definition MemoryUsage

NATO UNCLASSIFIED 248

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Determines the type of access that the virtual memory area is to have to the region
being attached.

Domain Values READ_ONLY

READ_WRITE

attached_here

Data Type Definition Address

Description Returns the logical address at which the region has been attached in the virtual
memory area’s memory space.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

Before a region can be detached, the region must be created using the createRegion service.

Associated Calls:

- createRegion,

- deleteRegion,

- attachAt,

- detach.

11.5.3.3.4 attachAt

Purpose:

Attach a memory region to a virtual memory area at a specified address.

Syntax:

MslStatus attachAt (
in PublicId reg ,
in PublicId dest_vm ,
in MemoryUsage usage ,
in Address attach_here );
Description:

This service makes the specified virtual memory area (dest_vm) aware of the region (reg) by updating
its internal tables to give the virtual memory area access to the physical memory associated with reg.
This access is limited to being either READ_ONLY or READ_WRITE according to the value of the
usage parameter. The service attaches the region at the logical address requested by the caller in the
attach_here parameter. Note that this service differs from the attach service since it does not
calculate the attachment address but requires it to be explicitly specified by the user.

The value MSL_OK shall be returned by the service if the region was attached successfully.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

NATO UNCLASSIFIED 249

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
Region ID.

Parameter Description:

reg

Data Type Definition PublicId

Description The identification number of the region to be attached, obtained by creating

the region using the createRegion service

Domain Values No limitation for this service.

dest_vm

Data Type Definition PublicId

Description The identification number of the virtual memory area to which attachment is to
occur, as obtained by creating the virtual memory area using the createVM
service.

Domain Values No limitation for this service.

usage

Data Type Definition MemoryUsage

Description Determines the type of access that the virtual memory area is to have to the
region being attached.

Domain Values READ_ONLY

READ_WRITE

attach_here

Data Type Definition Address

Description Contains the logical (linear) address at which the region is to be attached in
the virtual memory area’s memory space

Domain Values No limitation for this service.

Prerequisite Conditions:

Before a region can be attached, the region must be created using the createRegion service.

Associated Calls:

- createRegion,

- deleteRegion,

- attach,

- detach.

NATO UNCLASSIFIED 250

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.5.3.3.5 detach

Purpose:

Detach a memory region from a virtual memory area.

Syntax:

MslStatus detach (
in PublicId reg ,
in PublicId from );
Description:

Updates the internal data structures of a virtual memory area so that it no longer has access to the
specified memory region.

The value MSL_OK shall be returned by the service if the region was detached successfully.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
virtual memory area ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
Region ID.

The value MSL_INVALID_PARAMETER shall be returned by the service if it is called with an invalid
logical address.

Parameter Description:

reg

Data Type Definition PublicId

Description a unique identifier for the region to be detached from the virtual memory area, as
obtained when the region was originally created by calling the createRegion service.

Domain Values No limitation for this service.

from

Data Type Definition PublicId

Description A unique identifier for the virtual memory area from which the specified region is to be
detached, as obtained originally by creating the virtual memory area using the
createVM service.

Domain Values No limitation for this service.

Prerequisite Conditions:

Before a region can be detached, the region must be created using the createRegion service and
attached to a virtual memory area using the attach or attachAt service.

Associated Calls:

- createRegion,

- deleteRegion,

NATO UNCLASSIFIED 251

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- attach,

- attachAt,

- Board Services,

- NII,

- MOS extensions (OS, PCM, MMM).

11.6 SMBP

According to functional requirements the services are grouped into "use categories" - dependent on
the CFM types where the functions are implemented

Core SMBP Services

Available for use in all GSM on all CFM types

The comprehensive list of all SMBP calls is listed in Table 26 below. The specification of the RTBP
Tree Grammar is considered as a part of the SMBP services.

Table 26 - Overview of All SMBP Services

Service Group SMBP Call Description Use Section

Tree RTBP Tree Grammar RTBP Tree Grammar in EBNF core 11.6.1

Retrieving getRootNode Get the departure node of an RTBP tree core 11.6.2.1

Tables readNode Get a node with a specific identifier relative to the core 11.6.2.2
provided node

getNodeId Get the identifier corresponding to a node. core 11.6.2.3

getAttributes Get a buffer with the data stored with a provided core 11.6.2.4
node.

getChildNodes Get a list of all subsequent nodes relative to the core 11.6.2.5
provided node

getLength Get the number of node handles within a node core 11.6.2.6
list

item Retrieve a node handle from a node list, such as core 11.6.2.7
provided by getChildNodes.

11.6.1 RTBP Tree Grammar

11.6.1.1 Introduction

The RTBP tree is specified in the EBNF format, ISO 14977. See document reference [7].

NATO UNCLASSIFIED 252

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The basic grammar of the tree is based on a set of nodes that is a set of Ids with an associated child
node. The child node may be either an SMBP structure or a set of node itself. The basic structure of
that tree is a continuation of Ids that terminates with a table of data corresponding to SMBP structure.

Set_Node = (ID_CHILD, Child_Node) , {ID_CHILD , Child_Node } ;

Child_Node = Item_Node , { Item_Node } ;

Item_Node = Set_Node | SMBP_structure ;

The Id discriminates either the type of the child node or the node within this set. The Id
PROCESS_SET is the node where are located all nodes describing processes of the current
configuration. Process_Id is the node where all items describing that process are located.

ID_CHILD = ID_TYPE | ID_ITEM ;

ID_TYPE = PROCESS_FUNCTION_SET | FUNCTION_SET | GSM_CONFIG_DATA_SET |

STATE_MACHINE_SET | CONFIGURATION_SET | PROCESS_SET | PROCESS_ITEM |
THREAD_ITEM | SCHEDULING_ITEM | VCMAPPING_ITEM | VC_SET | TC_SET |
VC2TCMAPPING_SET | INTERFACE_SET | CFM_SET | CFM_ITEM | CFM_MLI_CHANNEL
| PE_SET | PE_ITEM | PE_MLI_CHANNEL | CLOCK_SET | CLOCK_ITEM |
FEDERATED_CLOCK_ITEM | STATE_ITEM | ACTION_SET;

ID_ITEM = Function_Id | GSM_data_Id | GSM_data_Id | StateMachine_Id |

Configuration_Id | Process_Id | Thread_Id | Scheduling_Id | VcMapping_Id |
Vc_Id | Vc_Table_Id | Tc_Id | Tc_Table_Id | Vc2TcMapping_Id |
Interface_Id | Cfm_Id | Cfm_Load_Id | Pe_Id | Pe_Load_Id | Clock_Id |
FederatedClock_Id | State_Id | Event_Id | Action_Id ;

11.6.1.2 Identifier Specification

Table 27 - Identifiers Described as ID_ITEM

Identifier Description

Function_Id The identification of a GSM Function, which is unique within an IMA System

GSM_data_Id The identification of a GSM configuration data, which is unique within a GSM
Function

StateMachine_Id The identification of a state machine, which is unique within a GSM Function

Configuration_Id The identification of a logical configuration, which is unique within an IMA System

Process_Id The identification of a process, which is unique within an IMA System

Thread_Id The identification of a thread, which is unique within a process

Scheduling_Id The identification of a scheduling information table, which is unique within a

process

VcMapping_Id The identification of a Mapping of a VC on a Process, which is unique within a

process

NATO UNCLASSIFIED 253

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Identifier Description

Vc_Id The identification of a VC, which is unique within an IMA System

Vc_Table_Id The identification of a table specifying a VC, which is unique within a VC

Tc_Id The identification of a TC, which is unique within an IMA System

Tc_Table_Id The identification of a table specifying a TC, which is unique within a TC

Vc2TcMapping_Id The identification of a Mapping of a VC onto a TC, which is unique within an IMA
System

Interface_Id The identification of an Interface, which is unique within an MSL implementation

Cfm_Id The identification of a CFM, which is unique within an IMA System

Cfm_Load_Id The identification of a table specifying a CFM download, which is unique within a
CFM

Pe_Id The identification of a Processing Element, which is unique within a CFM

Pe_Load_Id The identification of a table specifying a PE download, which is unique within a

Processing Element

Clock_Id The identification of a Clock, which is unique within an IMA System

FederatedClock_Id The identification of a Clock that is federated, which is unique within an IMA
System

State_Id The identification of a state, which is unique within a state machine. Actually it is
the current state.

Event_Id The identification of an event, which is unique within a state machine

Action_Id The identification of an action, which is unique within a transition that is defined by
the couple current state (State_Id) and event (Event_Id)

11.6.1.3 EBNF Specification

The Figure 48 in section 10.6.1 represents the RTBP Tree from a concept point of view. The following
table maps the terms used in the Concept Figure with the term identifying nodes in the EBNF
specification.

Table 28 - Mapping of EBNF Specification with RTBP Concept

Concept Tree EBNF Node Tree

GSM Process To Function Mapping PROCESS_FUNCTION_SET

GSM Function FUNCTION_SET

GSM Configuration Data GSM_CONFIG_DATA_SET

Logical Configuration CONFIGURATION_SET

NATO UNCLASSIFIED 254

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Concept Tree EBNF Node Tree

Interface Info INTERFACE_SET

Process Info PROCESS_ITEM

VC Mapping VCMAPPING_ITEM

Thread Info THREAD_ITEM

Scheduling Info SCHEDULING_ITEM

VC to TC Mapping VC2TCMAPPING_SET

VC Info VC_SET

TC Info TC_SET

State Machine STATE_MACHINE_SET

CFM Info CFM_SET

PE Info PE_SET

Clock Info CLOCK_SET

Federated Clock Info FEDERATED_CLOCK_SET

Root_Node = Function_Node ,
ProcessFunction_Node ;

FUNCTION_SET

Function_Id

ROOT

PROCESS_FUNCTION_SET

Process_Id

SMBP
Function_Id

Figure 55 - Root Definition

ProcessFunction_Node = PROCESS_FUNCTION_SET,
ProcessFunction_Set_Node ;

ProcessFunction_Set_Node = ( Process_Id , SMBP_Function_Id ) ,

NATO UNCLASSIFIED 255

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

{ Process_Id , SMBP_Function_Id } ;

Function_Node = FUNCTION_SET, Function_Set_Node ;

Function_Set_Node = ( Function_Id , Function_Child_Node ) ,

{ Function_Id , Function_Child_Node } ;

Function_Child_Node = [ Configuration_Node ] ,
[ StateMachine_Set_Node ] ,
[ GSM_Configuration_Data_Set_Node ] ;

CONFIGURATION_SET

Configuration_Id

Function_Id
STATE_MACHINE_SET

StateMachine_Id

GSM_CONFIG_DATA_SET

GSM_data_Id

Figure 56 - Function Set Definition

Configuration_Node = CONFIGURATION_SET ,
Configuration_Set_Node ;

Configuration_Set_Node =
( Configuration_Id , Configuration_Child_Node ) ,
{ Configuration_Id , Configuration_Child_Node } ;

Each configuration node has child nodes that are both optional and allow access to different types of
information. Possibly a configuration may contain only information to configure processes and its
associated communication object (e.g. Process_Set_Node and Vc_Set_Node) or communication onto
the network (e.g. Tc_Set_Node, Vc2TcMapping_Set_Node and Interface_Set_Node). It is up to the
system design to decide.

NATO UNCLASSIFIED 256

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

PROCESS_SET
Process_Id

VC_SET
Vc_Id

TC_SET

Tc_Id

VC2TCMAPPING_SET

Vc2TcMapping_Id
Configuration_Id

SMBP
VcToTcMapping
Description
INTERFACE_SET

Interface_Id

SMBP
CFM_SET InterfaceData

CLOCK_SET
Cfm_Id

Figure 57 - Configuration Set Definition

Configuration_Child_Node = [ Process_Set_Node ] ,
[ Vc_Set_Node ] ,
[ Tc_Set_Node ] ,
[ Vc2TcMapping_Set_Node ] ,
[ Interface_Set_Node ] ,
[ Cfm_Set_Node ] ,
[ Clock_Set_Node ] ;
Process_Set_Node = PROCESS_SET , Process_SetChild_Node ;

Process_SetChild_Node = ( Process_Id , Process_Child_Node ) ,

{ Process_Id , Process_Child_Node } ;

The Process_Child_Node gathers all information for configuring a Process. It comprises information
related to the Process, its Threads, and the scheduling parameters of these threads and the mapping
of VC of the present Process.

Process_Child_Node = Process_GrandChild_Node ,
Thread_Child_Node ,

NATO UNCLASSIFIED 257

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Scheduling_Child_Node ,
VCMapping_Child_Node ;

Process_GrandChild_Node = PROCESS_ITEM ,
SMBP_ProcessDescription ;

Thread_Child_Node = THREAD_ITEM , Thread_GrandChild_Node ;

Thread_GrandChild_Node =
( Thread_Id , SMBP_ThreadDescription ) ,
{ Thread_Id , SMBP_ThreadDescription } ;

Scheduling_Child_Node =
SCHEDULING_ITEM , Scheduling_GrandChild_Node ;

Scheduling_GrandChild_Node =
( Scheduling_Id , SMBP_ThreadSchedulingInfo ) ,
{ Scheduling_Id , SMBP_ThreadSchedulingInfo } ;
Each SMBP structure is
hooked to a unique Id

PROCESS_ITEM
SMBP
ProcessDescription

SMBP
THREAD_ITEM ThreadDescription
Thread_Id
Process_Id

SCHEDULING_ITEM
Scheduling_Id SMBP
ThreadScheduling
Info

VCMAPPING_ITEM

VcMapping_Id

SMBP
VcMapping
Description

Figure 58 - Process Set Definition

VCMapping_Child_Node =
VCMAPPING_ITEM , VCMapping_GrandChild_Node ;

VCMapping_GrandChild_Node =
( VcMapping_Id , SMBP_VcMappingDescription ) ,

NATO UNCLASSIFIED 258

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

{ VcMapping_Id , SMBP_VcMappingDescription } ;
Vc_Set_Node = VC_SET , Vc_Child_Node ;

Vc_Child_Node = ( Vc_Id , Vc_Item_Node ) ,

{ Vc_Id , Vc_Item_Node } ;

It shall be noticed the first part of Vc_Item_Node is for the case of mono processor architecture while
the second part is for multi processor architecture. This two definition are exclusive.

Vc_Item_Node =
SMBP_VcDescription |
( ( Vc_Table_Id , SMBP_VcDescription ) ,
{ Vc_Table_Id , SMBP_VcDescription } ) ;
Mono-Processor Environment

Vc_Id
SMBP_VcDescription

Multi-Processor Environment

Vc_Id

Vc_Table_Id

SMBP
VcDescription

Figure 59 - VC Set Definition

Tc_Set_Node = TC_SET , Tc_Child_Node ;

Tc_Child_Node = ( Tc_Id , Tc_Item_Node ) ,

{ Tc_Id , Tc_Item_Node } ;

Tc_Item_Node =
( Tc_Table_Id , SMBP_TcDescription ) ,
{ Tc_Table_Id , SMBP_TcDescription} ;
Vc2Tc_Set_Node = VC2TCMAPPING_SET , Vc2Tc_Child_Node ;

Vc2Tc_Child_Node =
( Vc2TcMapping_Id , SMBP_VcToTcMappingDescription ) ,
{ Vc2TcMapping_Id , SMBP_VcToTcMappingDescription } ;

NATO UNCLASSIFIED 259

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface_Set_Node = INTERFACE_SET , Interface_Child_Node ;

Interface_Child_Node =
( Interface_Id , SMBP_InterfaceData ) ,
{ Interface_Id , SMBP_InterfaceData } ;

Tc_Id

Tc_Table_Id

SMBP
TcDescription

Figure 60 - TC Set Definition

The Cfm_Set_Node gathers all information describing the set of remote CFM that are managed by
the present PE. It shall be noticed that the distant CFM does not necessarily have PE. The
Cfm_Mli_Node provides the information of the MLI channel to reach this CFM.

Cfm_Set_Node = CFM_SET , Cfm_SetChild_Node ;

Cfm_SetChild_Node = ( Cfm_Id , Cfm_Child_Node ) ,

{ Cfm_Id , Cfm_Child_Node } ;

Cfm_Child_Node = Cfm_GrandChild_Node ,
Cfm_Mli_Node ,
[Pe_Set_Node] ;

NATO UNCLASSIFIED 260

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Each SMBP structure is

hooked to a unique Id

CFM_ITEM

Cfm_Load_Id

SMBP
CfmDescription

CFM_MLI_CHANNEL

Cfm_Id
SMBP
MliChannel

PE_SET

Pe_Id

Figure 61 - CFM Set Definition

Cfm_GrandChild_Node = CFM_ITEM , Cfm_LoadChild_Node ;

Cfm_LoadChild_Node = ( Cfm_Load_Id , SMBP_CfmDescription ) ,

{ Cfm_Load_Id , SMBP_CfmDescription } ;

Cfm_Mli_Node = CFM_MLI_CHANNEL , SMBP_MliChannel ;

Pe_Set_Node = PE_SET , Pe_SetChild_Node ;

Pe_SetChild_Node = ( Pe_Id , Pe_Child_Node ) ,

{ Pe_Id , Pe_Child_Node } ;

Pe_Child_Node = Pe_GrandChild_Node ,
Pe_Mli_Node ;

NATO UNCLASSIFIED 261

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Each SMBP structure is

hooked to a unique Id

PE_ITEM

Pe_Load_Id

SMBP
CfmDescription
Pe_Id

PE_MLI_CHANNEL

SMBP
MliChannel

Figure 62 - PE Set Definition

Pe_GrandChild_Node = PE_ITEM , Pe_item_Node ;

Pe_item_Node = ( Pe_load_id , SMBP_CfmDescription ) ,
{ Pe_load_id , SMBP_CfmDescription } ;
Pe_Mli_Node = PE_MLI_CHANNEL , SMBP_MliChannel ;
Each SMBP structure is
hooked to a unique Id

CLOCK_ITEM

SMBP
ClockInfo

CLOCK_SET

FEDERATED_CLOCK_ITEM
Federated_Clock_Id

SMBP
FederatedClockInfo

Figure 63 - Clock Set Definition

Clock_Set_Node = CLOCK_SET , Clock_Child_Node ;

NATO UNCLASSIFIED 262

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Clock_Child_Node = Clock_GrandChild_Node ,
[FederatedClock_Child_Node] ;

Clock_GrandChild_Node = CLOCK_ITEM , SMBP_ClockInfo ;

FederatedClock_Child_Node =
FEDERATED_CLOCK_ITEM , FederatedClock_GrandChild_Node ;
FederatedClock_GrandChild_Node =
( FederatedClock_Id , SMBP_FederatedClockInfo ) ,
{ FederatedClock_Id , SMBP_FederatedClockInfo } ;

GSM_Configuration_Data_Set_Node =
GSM_CONFIG_DATA_SET,
GSM_Configuration_Data_GrandChild_Node;
GSM_Configuration_Data_GrandChild_Node =
( GSM_data_Id, SMBP_GsmConfigData ) ,
{ GSM_data_Id, SMBP_GsmConfigData } ;

StateMachine_Set_Node =
STATE_MACHINE_SET , StateMachine_Child_Node;
StateMachine_Child_Node =
( StateMachine_Id , StateMachine_GrandChild_Node ) ,
{ StateMachine_Id , StateMachine_GrandChild_Node } ;

StateMachine_Id

State_Id Event_Id

STATE_ITEM SMBP
State

TIMEOUT_ITEM SMBP
TimeInterval

Each SMBP structure is

hooked to a unique Id

ACTION_SET SMBP
Action
Action_Id

Figure 64 - State Machine Set Definition

StateMachine_GrandChild_Node = ( State_Id, Transition_Node ) ,

{ State_Id, Transition_Node } ;

NATO UNCLASSIFIED 263

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Transition_Node = ( Event_Id , Transition_Child_Node ) ,

{ Event_Id , Transition_Child_Node } ;

Transition_Child_Node = State_Node ,
Timeout_Node ,
Action_Node ;

State_Node = STATE_ITEM, SMBP_State ;

Timeout_Node = TIMEOUT_ITEM , SMBP_TimeInterval ;
Action_Node = ACTION_SET, Action_Child_Node;
Action_Child_Node = ( Action_Id , SMBP_Action ) ,
{ Action_Id , SMBP_Action } ;

11.6.2 Services for Retrieving Tables

11.6.2.1 getRootNode

Purpose:

Get the departure node of an RTBP tree.

Syntax:

ReturnStatus getRootNode (
out Node root_node );
Description:

The service gives the starting point of the RTBP tree. It shall be performed prior any SMBP services.

The service shall return ‘SUCCESS’ on successful completion else it shall return ‘ERROR’.

Parameter Description:

root_node

Data Type Definition Node

Description Returns the node handle of the root node.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The RTBP has been loaded.

Associated Calls:

None

NATO UNCLASSIFIED 264

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.6.2.2 readNode

Purpose:

Get a node with a specific identifier relative to the provided node.

Syntax:

ReturnStatus readNode (
in Node parent_node ,
in PublicId item_id ,
out Node node_id );
Description:

The service searches the RTBP tree under the provided node parent_node for the identifier item_id. If
it finds an appropriate node, this shall be provided in node parameter.

The service purpose is to provide the reference handle to that node that is identified by item_id. It is to
select a node from a tree. To retrieve the actual data referenced by that node, use getAttributes.

The service shall return ERROR when at least one an input parameter is invalid.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

parent_node

Data Type Definition Node

Description The Handle specifying the parent node used to search the the requested item in.

Domain Values No special values are associated with this parameter.

item_id

Data Type Definition PublicId

Description The identifier specifying a sub element to be returned in node.

Domain Values No special values are associated with this parameter.

node

Data Type Definition Node

Description The handle of the resulting node, which was selected with the above information.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The parent_node exists, as the service retrieves the information starting from the provided node.

Associated Calls:

- getRootNode.

NATO UNCLASSIFIED 265

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Example:

void handleProcessNode( PublicId configuration ,

PublicId process_id ,
ProcessDescription *process_desc)
{
// The present Example reaches from the root
// the node of a Process in a logical Configuration
// and retrieves the SMBP structure ProcessDescription

Node node_tmp ;

SMBP_getRootNode ( (Node *) &node_tmp) ;

SMBP_readNode
( (Node) node_tmp,
(PublicId) CONFIGURATION_SET ,
(Node*) &node_tmp ) ;
SMBP_readNode
( (Node) node_tmp,
(PublicId) configuration,
(Node*) &node_tmp ) ;
SMBP_readNode
( (Node) node_tmp,
(PublicId) PROCESS_SET,
(Node*) &node_tmp ) ;
SMBP_readNode
( (Node) node_tmp,
(PublicId) process_id,
(Node*) node_tmp) ;
SMBP_readNode
( (Node) node_tmp,
(PublicId) PROCESS_ITEM,
(Node*) node_tmp) ;
SMBP_getAttributes (
(Node) node_tmp,
(unsigned long)sizeof(ProcessDescription),
(Address) process_desc);
}

11.6.2.3 getNodeId

Purpose:

Get the identifier corresponding to a node.

Syntax:

ReturnStatus getNodeId(

NATO UNCLASSIFIED 266

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

in Node node_id ,
out PublicId identifier );
Description:

This service is used to retrieve the identifier of a given node.

If the specified node does not exist or has no identifier, the service shall return ERROR.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

node

Data Type Definition Node

Description The node to return the associated identifier.

Domain Values No special values are associated with this parameter.

identifier

Data Type Definition PublicId

Description The identifier associated to the node

Domain Values Depending on the node level. See ID_ITEM and ID_TYPE

Prerequisite Conditions:

Node must contain the handle to an existing node, which may be retrieved by invoking getRootNode
or readNode prior to this service.

Associated Calls:

- getRootNode,

- getChildNodes.

Example:

void handleProcessIdIteratively( Node configuration )

{
// The present Example processes iteratively the set of
// processes in a given configuration Node which has
// been previously reached by a configuration Id
//
// per_process_id_operation is an application function,
// which is called by this function for each node
// retrieved from the nodelist

int set_size , inc = 0 ;

Node process_set_node , process_id_node ,
process_desc_node ;

NATO UNCLASSIFIED 267

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NodeList process_set_list ;
PublicId process_id ;

SMBP_readNode
( (Node) configuration ,
(PublicId) PROCESS_SET ,
(Node*) &process_set_node ) ;

// At this point child nodes are a set of Process_Ids

SMBP_getChildNodes
( (Node) process_set_node,
(NodeList*) &process_set_list ) ;

SMBP_getLength
( (NodeList) process_set_list ,
(unsigned long*) &set_size ) ;
// The parameter set_size is the number of Process_Id
for( inc = 0 ; inc <= set_size ; inc += 1 )
{
// The node corresponding to each ProcessId are retrieved
SMBP_item
((NodeList) process_set_list ,
(Node*) &process_id_node) ;
// The Process Id is retrieved with the node
SMBP_getNodeId
( (Node) process_id_node , // Process Ids node
(PublicId *) &process_id ) ;

per_process_id_operation(
(PublicId *) process_id ) ;
}
}

11.6.2.4 getAttributes

Purpose:

Get a buffer with the data stored with a provided node.

Syntax:

ReturnStatus getAttributes(
in Node node_id ,
in unsigned long buffer_size ,
in Address buffer );
Description:

This service is used to retrieve the actual information from the runtime blueprints. The given node is
the origin of the returned data.

NATO UNCLASSIFIED 268

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The buffer parameter points to a caller memory area, which contains the requested data when the
service finishes successful.

If the specified node does not exist, the service shall return ERROR.

If buffer_size is less than the size of the RTBP data, the service shall return ERROR.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

node

Data Type Definition Node

Description The node to return the associated attributes from.

Domain Values No special values are associated with this parameter.

buffer_size

Data Type Definition Unsigned long

Description The maximal size of buffer where the RTBP data shall be copied

Domain Values No special values are associated with this parameter.

buffer

Data Type Definition Address

Description The pointer in the caller memory, where the RTBP information shall be copied.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

Node must contain the handle to an existing node, which may be retrieved by invoking getRootNode
prior to this service.

Associated Calls:

- getRootNode,

- readNode.

Example:

void handleThreadDirectly(Node node_thread_id,

ThreadDescription *thread_desc)
{
SMBP_getAttributes (
node_thread_id, // thread node
sizeof(ThreadDescription),
(Address) thread_desc);

NATO UNCLASSIFIED 269

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.6.2.5 getChildNodes

Purpose:

Get a list of all subsequent nodes relative to the provided node.

Syntax:

ReturnStatus getChildNodes (
in Node parent_node ,
out NodeList node_list );
Description:

The service shall provide a node_list, which contains a list of all node handles being children of
parent_node.

The service getLength gives the number of child nodes. If there is no child the service getLength shall
give a zero value.

The service shall initialise the iterator within the NodeList to the zero value.

If the parent_node does not exist the service shall return ERROR.

The service shall return SUCCESS on successful completion.

Parameter Description

parent_node

Data Type Definition Node

Description The node handle referencing the parent node precedes the requested child nodes in
the tree hierarchy.

Domain Values No special values are associated with this parameter.

node_list

Data Type Definition NodeList

Description A handle to a list of all subsequent nodes relative to the provided parent_node. The
list is capable of maintaining an iterator by it.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

A node handle of an existing parent_node must be provided.

Associated Calls:

- getLength,

- item.

NATO UNCLASSIFIED 270

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Example:

void handleProcessDescription Iteratively( Node configuration )

{
// The present Example processes iteratively the set of
// processes in a given configuration Node which has
// been previously reached by a configuration Id
//
// per_process_desc_operation is an application function,
// which is called by this function for each node
// retrieved from the nodelist

int set_size , inc = 0 ;

Node process_set_node , process_id_node ,
process_desc_node ;
NodeList process_set_list ;
ProcessDescription process_desc ;

SMBP_readNode
( (Node) configuration ,
(PublicId) PROCESS_SET ,
(Node*) &process_set_node ) ;

// At this point child nodes are a set of Process_Ids

SMBP_getChildNodes
( (Node) process_set_node,
(NodeList*) &process_set_list ) ;

SMBP_getLength
( (NodeList) process_set_list ,
(unsigned long*) &set_size ) ;
// The parameter set_size is the number of Process_Id
for( inc = 0 ; inc < set_size ; inc = inc + 1 )
{
// The node corresponding to each ProcessId are retrieved
SMBP_item
((NodeList) process_set_list ,
(Node*) &process_id_node) ;
// From the node specified by the Identifier PROCESS_ITEM
// the SMBP structure ProcessDescription is retrievable
SMBP_readNode
( (Node) process_id_node , // Process Ids node
(PublicId) PROCESS_ITEM ,
(Node*) &process_desc_node ) ;

NATO UNCLASSIFIED 271

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

SMBP_getAttributes (
(Node) process_desc_node , // ProcessDescription node
(unsigned long) sizeof(ProcessDescription),
(Address) &process_desc);

per_process_desc_operation(
(ProcessDescription *) process_desc ) ;
}
}

11.6.2.6 getLength

Purpose:

Get the number of node handles within a node list.

Syntax:

ReturnStatus getLength (
in NodeList node_list ,
out unsigned long set_size );
Description:

The given node_list is a list of node handles, such as provided by the service getChildNodes. The
service shall provide the number of node handles within this provided list in the set_size parameter.

If the node list is empty the number of node handles is set to the zero value.

The service shall return ‘SUCCESS’ on successful completion else it shall return ‘ERROR’.

Parameter Description

node_list

Data Type Definition NodeList

Description The list of nodes, such as provided by getChildNodes.

Domain Values No special values are associated with this parameter.

set_size

Data Type Definition unsigned long

Description The number of elements contained by node_list.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

NATO UNCLASSIFIED 272

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- getChildNodes.

11.6.2.7 item

Purpose:

Retrieve a node handle from a node list, such as provided by getChildNodes.

Syntax:

ReturnStatus item (
in NodeList node_list ,
out Node node_id );
Description:

Each call of the present service shall provide a node handle from the node list and internally advance
to the next node. This enables the caller to iterate through the provided node list and retrieve all
stored node handles successively.

The given node_list parameter provides a list of nodes, such as provides by the getChildNodes
service. Additionally, it includes an iterator that has been set to zero by the service getChildNodes
and, is incremented by the present service.

The node parameter returns the node handle internally selected.

If the list is empty or the end of the list has been reached, the service shall return ERROR.

If any other error occurs and prevents the service from successful completion, the service shall return
ERROR.

The service shall return SUCCESS on successful completion.

Parameter Description:

node_list

Data Type Definition NodeList

Description The list containing the node handles to be retrieved one by one, each with a separate
service call.

Domain Values No special values are associated with this parameter.

node

Data Type Definition Node

Description This is the handle of a node retrieved from the provided node_list. Each call of this
service shall provide a new node, or an empty handle if the list has reached its end.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

NATO UNCLASSIFIED 273

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The node_list has been provided by the service getChildNodes. The number of node handles has
been provided by the service getLength.

Associated Calls:

- getChildNodes,

- System management data structures,

- SMBP services.

11.7 SMOS

According to functional requirements the services are grouped into "use categories" - dependent on
the CFM types where the functions are implemented

- Core SMOS Services

Available for use in all GSM on all CFM types

The comprehensive list of all SMOS calls is listed in Table 29 below.

Table 29 - Overview of all SMOS Services

Service Group SMOS Call Description Use Section

Process and createProcess Create a process with specified

core 11.7.1.1
Thread resources
Management
createThread Create a thread context with specified
core 11.7.1.2
resources within an existing process

runProcess Run a process core 11.7.1.3

stopProcess Stop a Process core 11.7.1.4

destroyProcess Free resources of the specified process

core 11.7.1.5
and its associated threads

Define the scheduling behaviour for a

setSchedulingParameters thread denoted by process id and core 11.7.1.6
thread id

getThreadState Provide the current status of a thread in

core 11.7.1.7
a process

Fault getError Wait for an error to occur and provide

core 11.7.2.1
Management error information to the caller

activateErrorHandler Activate the error handler in a Process core 11.7.2.2

VC createVirtualChannel Initialise OS resources for

core 11.7.3.1
Configuration communication through a VC

destroyVC Free OS resources associated with the

core 11.7.3.2
specified VC

NATO UNCLASSIFIED 274

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group SMOS Call Description Use Section

attachChannel Attach process local VC to global VC

ToProcessOrThread core 11.7.3.3
resources

detachAllThreads Detach global VC resources from a

OfProcessFromVc core 11.7.3.4
Process

attachTransferConnection
ToVirtualChannel Attach VC with TC core 11.7.3.5

detachTransferConnection
FromVirtualChannel Detach VC from TC core 11.7.3.6

Network configureInterface Configure an Interface in the Module core 11.7.4.1

Configuration

createTC Create a TC core 11.7.4.2

destroyTC Destroy a TC core 11.7.4.3

getNetworkPortStatus Get the status of a local CFM network

core 11.7.4.4
port

Security getPMData Wait for a protectively marked data core 11.7.5.1

Management Return the protectively marked data

returnPMData previously retrieved by getPMData to core 11.7.5.2
the OS

getAuditData Wait for a security breach to occur and

core 11.7.5.3
retrieve associated data from the OS

erasePhysicalMemory Erase a physical memory for local CFM core 11.7.5.4

Built-In Test getPbitResult Get the Power-up Built In Test (PBIT)

core 11.7.6.1
Management result

startCbit Start Continuous Built In Test (CBIT) core 11.7.6.2

getCbitResult Get the Continuous Built In Test (CBIT)

core 11.7.6.3
result

startIbit Start Initiated Built In Test (IBIT) core 11.7.6.4

getIbitResult Get the Initiated Built In Test (IBIT)

core 11.7.6.5
result

CFM getMyCfmStatus Get the status of the CFM core 11.7.7.1

Information

getMyCfmInfo Get the characteristics of the CFM core 11.7.7.2

getMyPeId Get the identifier of the PE core 11.7.7.3

CFM requestDownloadToCfm Request download of data to a remote core 11.7.8.1

NATO UNCLASSIFIED 275

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Service Group SMOS Call Description Use Section

Resources CFM

Management getRemoteInfo Get information from a distant CFM core 11.7.8.2

Time configureClock Configure the clock mode of the Module core 11.7.9.1
Management

attachFederatedClock Attach a federated clock to the Module

core 11.7.9.2
clock

Logging readLog Request to the OS to read a message in 11.7.10.

core
Management the log device 1

writeLog Write a message to the OS to be written 11.7.10.

core
in the log device 2

getLogReport Retrieves an application log message 11.7.10.

core
from an application thread 3

11.7.1 Process and Thread Management Services

11.7.1.1 createProcess

Purpose:

Create a process with specified resources.

Syntax:

TimedReturnStatus createProcess (
in ProcessDescription process_desc );
Description:

This service shall provide a protected memory area for the process, load the executable file from the
local memory or a remote Module into this memory area and initiate the process. When a remote
download is necessary, it shall use the dedicated OLI services Request and Reply Read File. See
section 12.4.2.1.2.2.

This service shall allocate all necessary resources to create the process. The created process shall
be in the ‘INITIALISED’ state.

An ‘TM_ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with an other one or invalid comparing
its expected value by the OS,

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

- The process already exists.

A ‘TM_TIMEOUT’ condition shall be returned when the specified process has not been created in the
required time.

NATO UNCLASSIFIED 276

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The service shall return ‘TM_SUCCESS’ on successful completion.

Parameter Description:

process_desc

Data Type Definition ProcessDescription

Description The process description that is provided by the blueprints.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The process does not exist.

Associated Calls:

- runProcess,

- stopProcess,

- destroyProcess.

11.7.1.2 createThread

Purpose:

Create a thread context with specified resources within an existing process.

Syntax:

ReturnStatus createThread (
in ThreadDescription thread_desc );
Description:

This service shall initialise the context of a thread in a process. The initialisation state of the thread
shall be ‘DORMANT’ except for the main thread, which shall be created into ‘READY’ state. The main
thread is identified by the thread id value one.

An ‘ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with an other one or invalid comparing
its expected value by the OS,

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

- The thread already exists,

- The specified process does not exist,

- The specified process is not in the INITIALISED state.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

NATO UNCLASSIFIED 277

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

thread_desc

Data Type Definition ThreadDescription

Description The thread description that is provided by the blueprints.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The process has been created and is in INITIALISED state. The thread does not exist.

Associated Calls:

- createProcess,

- setSchedulingParameters.

11.7.1.3 runProcess

Purpose:

Run a process.

Syntax:

ReturnStatus runProcess (
in PublicId process_id );
Description:

This service shall enable scheduling for all threads belonging to the selected process.

An ‘ERROR’ condition shall be returned when:

- The specified process does not exist,

- The specified process is in RUNNING state,

- The main thread has not been created.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

process_id

Data Type Definition PublicId

Description The process identifier is unique in an ASAAC system.

Domain Values No limitation for this service.

Prerequisite Conditions:

The process and the main thread have been previously created and the process is not in RUNNING
state.

NATO UNCLASSIFIED 278

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- createProcess,

- createThread,

- stopProcess.

11.7.1.4 stopProcess

Purpose:

Stop a process.

Syntax:

ReturnStatus stopProcess (
in PublicId process_id );
Description:

This service shall disable scheduling for all threads belonging to the selected process.

An ‘ERROR’ condition shall be returned when:

- The specified process does not exist,

- The specified process is not in RUNNING state.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

process_id

Data Type Definition PublicId

Description The process identifier is unique in an ASAAC system.

Domain Values No limitation for this service.

Prerequisite Conditions:

The process is in RUNNING state.

Associated Calls:

- runProcess.

11.7.1.5 destroyProcess

Purpose:

Free the resources of the specified process and its associated threads.

Syntax:

NATO UNCLASSIFIED 279

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReturnStatus destroyProcess (
in PublicId process_id );
Description:

This service shall free process memory resources and clean scheduler states of all threads belonging
to this process whatever its state.

If the process is not RUNNING, the service shall destroy it. If the process is RUNNING, the service
shall stop it and then destroy it.

An ‘ERROR’ condition shall be returned when the specified process does not exist.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

process_id

Data Type Definition PublicId

Description The process identifier is unique in an ASAAC system.

Domain Values No limitation for this service.

Prerequisite Conditions:

The process has been created.

Associated Calls:

- createProcess,

- runProcess,

- stopProcess.

11.7.1.6 setSchedulingParameters

Purpose:

Define the scheduling behaviour for a thread denoted by process id and thread id.

Syntax:

ReturnStatus setSchedulingParameters (
in ThreadSchedulingInfo thread_scheduling_info );
Description:

This service shall set the scheduling behaviour of a thread in a process. The process shall be in
STOPPED or INITIALISED state.

An ‘ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with another one or invalid comparing its
expected value by the OS,

NATO UNCLASSIFIED 280

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

- The specified thread does not exist,

- The specified process does not exist,

- The specified process is in the RUNNING state.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

thread_scheduling _info

Data Type Definition ThreadSchedulingInfo

Description Structure describing to the scheduler the parameters of the scheduling policy.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The process has been created and is in STOPPED or INITIALISED state. The thread has been
created.

Associated Calls:

- createProcess,

- createThread.

11.7.1.7 getThreadState

Purpose:

Provide the current status of a thread in a process.

Syntax:

ReturnStatus getThreadState (
in PublicId process_id ,
in PublicId thread_id ,
out ThreadStatus thread_status );
Description:

This service shall return the current status of the selected thread.

If the input parameters specify a process or a thread that does not exist, an ‘ERROR’ condition shall
be returned.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

process_id

NATO UNCLASSIFIED 281

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition PublicId

Description The process identifier is unique in an ASAAC system.

Domain Values No limitation for this service.

thread_id

Data Type Definition PublicId

Description The thread identifier is unique within a process and defined in the blueprints.

Domain Values No limitation for this service.

thread_status

Data Type Definition ThreadStatus

Description The value of the thread status for the selected thread:

Domain Values All value of the enum type ThreadStatus.

Prerequisite Conditions:

The process and the thread have been previously created.

Associated Calls:

- createProcess,

- createThread.

11.7.2 Fault Management Services

11.7.2.1 getError

Purpose:

Wait for an error to occur and provide error information to the caller.

Syntax:

TimedReturnStatus getError (
out ErrorInfo error_info ,
in TimeInterval time_out );
Description:

This service shall block the caller until the OS reports an error or the timeout occurs. The service shall
provide information related to the error.

An ‘TM_ERROR’ condition shall be returned whether the service has not been performed properly.

An ‘TM_TIMEOUT’ condition shall be returned whether the time-out has been reached.

The service shall return ‘TM_SUCCESS’ on successful completion.

NATO UNCLASSIFIED 282

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Parameter Description:

error_info

Data Type Definition ErrorInfo

Description The Information corresponding to the object that has raised the Error

Domain Values No limitation.

time_out

Data Type Definition TimeInterval

Description Time-out

Domain Values Refer to TimeInterval domain values

Prerequisite Conditions:

None.

Associated Calls:

- activateErrorHandler,

- raiseApplicationError,

- getErrorInformation.

11.7.2.2 activateErrorHandler

Purpose:

Request the activation of an application error handler.

Syntax:

TimedReturnStatus activateErrorHandler (
in PublicId process_id ,
in PublicId faulty_thread_id ,
in ErrorType error_type ,
in ErrorCode error_code ,
in CharacterSequence error_message ,
out ReturnStatus error_handler_status ,
in TimeInterval time_out );
Description:

The OS shall start the Error Handler that is the Thread Id number one of the Application specified by
process_id.

The OS shall provide the information faulty_thread_id, error_code and error_message

shall be provided to Error Handler.

The service is blocking until the Error Handler terminates its processing or the time_out has been
reached.

NATO UNCLASSIFIED 283

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- When the service is completed successfully, it returns TM_SUCCESS. In this case the
error_handler_status reflects the termination status of the application error handler that has been
invoked,

- When process_id is out of range, it returns TM_ERROR,

- When faulty_thread_id is out of range, it returns TM_ERROR,

- When error_type is out of range, it returns TM_ERROR,

- When time_out has been reached, it returns TM_TIMEOUT.

Parameter Description:

process_id

Data Type Definition PublicId

Description This Id identifies the Process Application that has raised the Error

Domain Values 0..232-1

faulty_thread_id

Data Type Definition PublicId

Description This Id identifies the thread that has raised the Error

Domain Values 0..232-1

error_type

Data Type Definition ErrorType

Description The kind of Error that has been raised.

Domain Values Only APPLICATION_ERROR and APOS_CLIENT_ERROR are applicable.

error_code

Data Type Definition ErrorCode

Description The Code corresponding to the Error that has been raised

Domain Values Refer to ErrorCode domain values

error_message

Data Type Definition CharacterSequence

Description The Message corresponding to the Error that has been raised

Domain Values No special values are associated with this parameter.

error_handler_status

NATO UNCLASSIFIED 284

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition ReturnStatus

Description This is the status the application error handler has emitted when terminating

Domain Values No special values are associated with this parameter.

time_out

Data Type Definition TimeInterval

Description Time-out

Domain Values Refer to TimeInterval domain values

Prerequisite Conditions:

None.

Associated Calls:

- raiseApplicationError,

- getErrorInformation.

11.7.3 VC Configuration Services

11.7.3.1 createVirtualChannel

Purpose:

Initialise OS resources for communication through a VC.

Syntax:

ReturnStatus createVirtualChannel (
in VcDescription vc_desc );
Description:

This service shall create the local references of the VC inside the OS and allocate the required buffer
resources. The two ends of the VC (if any) calls this function the same way. There is no
synchronisation implied by this service between the two ends of the VC. This service is only aimed at
creating structures inside the local OS for the future management of the VC.

The service defines and allocates the total number and sizes of message buffers, which are available
for this VC for the use in buffer services (lockBuffer, sendBuffer, receiveBuffer, unlockBuffer). It
further defines the maximum number of TC's available. Further it provides the data presentation,
which may be used by the OS in order to convert the payload data of VC messages arriving from
remote CFM.

An ‘ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with an other one or invalid comparing
its expected value by the OS,

NATO UNCLASSIFIED 285

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

- The VC already exists.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_desc

Data Type Definition VcDescription

Description Describes the properties of a VC.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The VC does not exist.

Associated Calls:

- attachChannelToProcessOrThread,

- attachTransferConnectionToVirtualChannel.

11.7.3.2 destroyVirtualChannel

Purpose:

Free OS resources associated with the specified VC.

Syntax:

ReturnStatus destroyVirtualChannel (
in PublicId vc_id );
Description:

This service shall remove a VC and release resources. Prior to this call all processes and threads and
the eventual TC(s) shall have been detached.

An ‘ERROR’ condition shall be returned when:

- The VC does not exist,

- The VC is attached to either a Process or a TC.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_id

Data Type Definition PublicId

NATO UNCLASSIFIED 286

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The VC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

Prerequisite Conditions:

The VC exists and is not attached to any Process or TC.

Associated Calls:

- detachAllThreadsOfProcessFromVc,

- detachTransferConnectionFromVirtualChannel.

11.7.3.3 attachChannelToProcessOrThread

Purpose:

Attach process local VC to global VC resources.

Syntax:

ReturnStatus attachChannelToProcessOrThread (
in VcMappingDescription vc_mapping );
Description:

This service shall describe to the OS that a thread in a process is allowed to receive and send on a
VC. This service describes a local connection to the VC and provides a description for the memory
allocations associated to each thread end of the VC’s.

The service allocates buffer resources that are required for sending and receiving messages
(sendMessage, receiveMessage, sendMessageNonblocking, receiveMessageNonblocking) through
the attached VC and associates these buffer resources with the specified process and the specified
thread.

Prior to this service call, the VC and the process and thread shall have been created. The Process
shall be in ‘STOPPED’ or ‘INITIALISED’ state

The directions of the VC mapping and the VC are compatible:

- VC mapped as receiving shall only be attached to Receiving VC,

- VC mapped as sending shall only be attached to Sending VC.

The service shall conform to the requirement of the ASAAC Communication:

- A receiving VC may be attached to many Processes or Threads (1:N multicast),

- A sending VC shall be attached to a process only once.

An ‘ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with another one or invalid comparing its
expected value by the OS,

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

NATO UNCLASSIFIED 287

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- The VC does not exist,

- The Process do not exist,

- The thread do not exist as long as it is a reading VC or in a Multi-Processor environment,

- The Process is in the RUNNING state,

- The direction of both the VC and the TC are not compatible,

- The attachment does not conform to the Multicast requirement.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_mapping

Data Type Definition VcMappingDescription

Description The mapping of a VC onto a Process or Thread.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The VC and the Process or Thread exists. The Process is in STOPPED or INITIALISED state.

Associated Calls:

- createVirtualChannel,

- createProcess,

- stopProcess.

11.7.3.4 detachAllThreadsOfProcessFromVc

Purpose:

Detach global VC resources from a Process.

Syntax:

ReturnStatus detachAllThreadsOfProcessFromVc (
in PublicId vc_id ,
in PublicId process_id );
Description:

This service shall disassociate all threads of a process to a VC and release all VC buffer resources
that are associated with the specified process and the specified VC.

Prior to this service call the Process shall be in ‘STOPPED’ or ‘INITIALISED’ state.

An ‘ERROR’ condition shall be returned when:

NATO UNCLASSIFIED 288

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- The VC does not exist,

- The Process does not exist,

- The Process is in RUNNING state,

- There is no attachment between the Process and the VC.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_id

Data Type Definition PublicId

Description The VC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

process_id

Data Type Definition PublicId

Description The process identifier is unique in an ASAAC system.

Domain Values No limitation for this service.

Prerequisite Conditions:

The VC and the Process exist and have been attached. The Process is in STOPPED or INITIALISED
state.

Associated Calls:

- createVirtualChannel,

- createProcess,

- stopProcess,

- attachChannelToProcessOrThread.

11.7.3.5 attachTransferConnectionToVirtualChannel

Purpose:

Attach VC with TC.

Syntax:

ReturnStatus attachTransferConnectionToVirtualChannel (
in VcToTcMappingDescription vc_to_tc_mapping );
Description:

This service shall associate a TC to a VC.

NATO UNCLASSIFIED 289

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The directions of the TC and the VC are compatible:

- Receiving TC shall only be attached to receiving VC,

- Sending TC shall only be attached to Sending VC.

The service shall conform to the requirement of the ASAAC Communication:

- A sending VC may be attached to many Sending TC (1:N multicast),

- A receiving VC shall be attached to receiving TC only once.

An ‘ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with an other one or invalid comparing
its expected value by the OS,

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources,

- The VC does not exist,

- The TC does not exist,

- The direction of both the VC and the TC are not compatible,

- The attachment does not conform to the Multicast requirement.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_to_tc_mapping

Data Type Definition VcToTcMappingDescription

Description The mapping of a VC onto a TC.

Domain Values No limitation for this service

Prerequisite Conditions:

The VC and the TC exist.

All peers of the VC shall be ready before it is attached.

Associated Calls:

- createTransferConnection,

- createVirtualChannel.

11.7.3.6 detachTransferConnectionFromVirtualChannel

Purpose:

Detach VC from TC.

NATO UNCLASSIFIED 290

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Syntax:

ReturnStatus detachTransferConnectionFromVirtualChannel (
in PublicId vc_id ,
in PublicId tc_id );
Description:

This service shall disassociate a TC to a VC.

An ‘ERROR’ condition shall be returned when:

- The VC does not exist,

- The TC does not exist,

- There is no attachment between the TC and the VC.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

tc_id

Data Type Definition PublicId

Description The TC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

vc_id

Data Type Definition PublicId

Description The VC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

Prerequisite Conditions:

The VC and the TC exist and have been attached.

Associated Calls:

- createTransferConnection,

- createVirtualChannel,

- attachTransferConnectionToVirtualChannel.

11.7.4 Network Configuration Services

11.7.4.1 configureInterface

Purpose:

NATO UNCLASSIFIED 291

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Configure an Interface in the Module.

Syntax:

ReturnStatus configureInterface (
in InterfaceData if_config );
Description:

The service shall be used to configure an interface local to the Module, which may be for any scope of
communications (i.e. internal to a module or between modules). An interface can be either a physical
interface (e.g. a physical Network) or a logical interface (NII).

The OS conveys this request to configure the interface to the MOS.

If this call fails, no operation through this network interface shall be possible; i.e. this call shall
successfully complete before any other communications service call.

An ‘ERROR’ condition shall be returned when the request at MOS interface of configuring the
interface has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

If_config

Data Type Definition InterfaceData

Description Describes the properties of an physical or logical Interface.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- createTransferConnection.

11.7.4.2 createTransferConnection

Purpose:

Create a TC.

Syntax:

ReturnStatus createTransferConnection (
in TcDescription tc_desc );
Description:

The service shall be used to configure the resources to provide information required for the
transmission or reception of information over a TC (TC).

NATO UNCLASSIFIED 292

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The structure TcDescription defines the association of a TC identifier with a NetworkDescriptor. The
TC is a end-to-end unidirectional connection and the routing between the two end-points may be
defined by several couples of a TC identifier and a NetworkDescriptor. Multiple calls of this service
are possible with either the same TC identifier but different NetworkDescriptor or the same
NetworkDescriptor but different TC identifier.

The OS replies this request to create the TC at MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of creating the TC has
failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

tc_desc

Data Type Definition TcDescription

Description Describes the properties of a segment of a TC.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The interface has been configured.

Associated Calls:

- configureInterface,

- attachTransferConnectionToVirtualChannel.

11.7.4.3 destroyTransferConnection

Purpose:

Destroy a TC.

Syntax:

ReturnStatus destroyTransferConnection (
in PublicId tc_id ,
in NetworkDescriptor network_descr );
Description:

The service shall be used to release resources previously allocated to handle the transmission or
reception of information over a TC (TC). Following this service completion, the TC shall no longer be
operational.

This TC shall not be attached to any VC prior to this call. If not, the
detachTransferConnectionFromVirtualChannel shall be called prior to this call.

The OS replies this request to destroy the TC at MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of destroying the TC has
failed.

NATO UNCLASSIFIED 293

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

An ‘ERROR’ condition shall be returned whether the TC is attached to a VC.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

tc_id

Data Type Definition PublicId

Description The TC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

network_desc

Data Type Definition NetworkDescriptor

Description It identifies the segment of the TC to be destroyed

Domain Values No limitation for this service.

Prerequisite Conditions:

The TC has been configured and is not attached to a VC.

Associated Calls:

- createTransferConnection,

- detachTransferConnectionFromVirtualChannel.

11.7.4.4 getNetworkPortStatus

Purpose:

Get the status of a local CFM network port.

Syntax:

ReturnStatus getNetworkPortStatus (
in NetworkDescriptor network_desc ,
out NetworkPortStatus network_status ) ;
Description:

The service shall be used to determine the status of a port on a network locally to the Module. The
OS replies to this request by getting the Network Status at the MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of getting the Network
Status has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

NATO UNCLASSIFIED 294

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

network_desc

Data Type Definition NetworkDescriptor

Description It identifies the network and the port to be assessed.

Domain Values No limitation for this service.

network_status

Data Type Definition NetworkPortStatus

Description The status of the port of the Network.

Domain Values HEALTHY : the port is healthy

FAULTY : the port is faulty

Prerequisite Conditions:

The interface of that port of that Network has been configured.

Associated Calls:

- configureInterface.

11.7.5 Security Management Services

11.7.5.1 getPMData

Purpose:

Wait for a protectively marked data.

Syntax:

TimedReturnStatus getPMData (
out PublicId vc_id ,
out Address message_buffer_reference ,
in unsigned long max_msg_length ,
out unsigned long msg_length ,
in TimeInterval timeout );
Description:

This is a blocking service that is used by the SM in order to receive requests from the OS for data to
be processed (i.e. encrypted, decrypted, authenticated, verification of authentication).

This service shall block the caller until the OS detects that a message has arrived on a VC that is
marked for secure communications or the timeout occurs. The service shall provide the protectively
marked data and related information. The SM shall use the vc_id in order to determine the operation
to be performed on the protectively marked data (e.g. encryption).

An ‘TM_ERROR’ condition shall be returned when the service has not been performed correctly.

A ‘TM_TIMEOUT’ condition shall be returned when the time-out has been reached.

NATO UNCLASSIFIED 295

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The service shall return ‘TM_SUCCESS’ on successful completion.

Parameter Description:

vc_id

Data Type Definition PublicId

Description The VC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

msg_buffer

Data Type Definition MessageBufferReference

Description A reference to the message buffer within the process’s space.

Domain Values No limitation for this service

max_msg_length

Data Type Definition unsigned long

Description Maximum length of the buffer, which is provided by the caller, in bytes

Domain Values No limitation for this service

msg_length

Data Type Definition unsigned long

Description Actual length of the message in bytes.

Domain Values No limitation for this service

timeout

Data Type Definition TimeInterval

Description Time-out

Domain Values Refer to TimeInterval domain values

Prerequisite Conditions:

None

Associated Calls:

- returnPMData.

11.7.5.2 returnPMData

Purpose:

NATO UNCLASSIFIED 296

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Return the protectively marked data previously retrieved by getPMData to the OS.

Syntax:

ReturnStatus returnPMData (
in PublicId vc_id ,
in Address message_buffer_reference ,
in unsigned long msg_length ,
in ReturnStatus sm_return_status );
Description:

This is service is used by the SM in order to return the data that the OS has requested to be
processed (encrypted, decrypted, authenticated, or verification of encryption), once the required
action has taken place.

An ‘ERROR’ condition shall be returned when the service has not been performed correctly.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

vc_id

Data Type Definition PublicId

Description The VC identifier is unique in an ASAAC system.

Domain Values No limitation for this service

msg_buffer

Data Type Definition MessageBufferReference

Description A reference to the message buffer within the process’s space.

Domain Values No limitation for this service

msg_length

Data Type Definition unsigned long

Description Length of the message in bytes.

Domain Values No limitation for this service

sm_return_status

Data Type Definition ReturnStatus

Description A return type used to inform the OS of the state of the returned data (e.g. if the data
has been decrypted correctly).

Domain Values Refer to ReturnStatus domain values

Prerequisite Conditions:

The service getPMData must have completed correctly.

NATO UNCLASSIFIED 297

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- getPMData.

11.7.5.3 getAuditData

Purpose:

Wait for a security breach to occur and retrieve associated data from the OS.

Syntax:

TimedReturnStatus getAuditData (
out BreachType breach_type ,
out CharacterSequence audit_message ,
out Time rel_time ,
out Time abs_time ,
in TimeInterval time_out );
Description:

This service shall block the caller until the OS reports a security breach or the timeout occurs. The
service shall provide information related to the breach.

An ‘TM_ERROR’ condition shall be returned when the service has not been performed correctly.

An ‘TM_TIMEOUT’ condition shall be returned when the time-out has been reached.

The service shall return ‘TM_SUCCESS’ on successful completion.

Parameter Description:

breach_type

Data Type Definition BreachType

Description The Type corresponding to the security breach that has been raised

Domain Values Refer to BreachType domain values

audit_message

Data Type Definition CharacterSequence

Description The message corresponding to the security breach that has been raised. The
structure includes the actual length.

Domain Values No special values are associated with this parameter.

rel_time

Data Type Definition Time

Description The RLT when the error has occurred

Domain Values Refer to Time domain values for RLT

NATO UNCLASSIFIED 298

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

abs_time

Data Type Definition Time

Description The ALT when the error has occurred

Domain Values Refer to Time domain values for ALT

time_out

Data Type Definition TimeInterval

Description Time-out

Domain Values Refer to TimeInterval domain values

Prerequisite Conditions:

None.

Associated Calls:

None

11.7.5.4 erasePhysicalMemory

Purpose:

Erase a physical memory for local CFM.

Syntax:

ReturnStatus erasePhysicalMemory ();

Description:

This call shall be used when it is necessary to quickly erase physical memory on a given CFM. The
action will be instigated by the CM, which will use this SMOS call through to the OS, which will then
use a reflected MOS call through to the MSL. It is expected that the actual erasure will be executed in
hardware.

An ‘ERROR’ condition shall be returned when the service has not been performed correctly.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

None.

Prerequisite Conditions:

None.

Associated Calls:

None.

NATO UNCLASSIFIED 299

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.7.6 Built-In Test Management Services

11.7.6.1 getPbitResult

Purpose:

Get the Power up Built In Test result.

Syntax:

ReturnStatus getPbitResult (
out PbitResult pbit_result );
Description:

This service shall get the PBIT result. It conveys the PBIT result as provided by the MSL at the MOS
interface.

An ‘ERROR’ condition shall be returned when the retrieval of the PBIT result from the MSL has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

pbit_result

Data Type Definition PbitResult

Description The PBIT result

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The PBIT has been performed.

Associated Calls:

None

11.7.6.2 startCbit

Purpose:

This service starts the continuous built-in test monitoring.

Syntax:

ReturnStatus startCbit (
in unsigned long test_code ,
in CbitModeType mode ,
out BitTestStatus bit_test_status );
Description:

The service startCbit is used to perform a CBIT test. When the call is made the CBIT software will run
a specified test, given as an input parameter, for a predetermined period and then return. The

NATO UNCLASSIFIED 300

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

predetermined period will be system specific. The CBIT test software must be written to return within
this period. If the test is autonomous the call will check the state of the ongoing test and return the
status. If the test requires the processor to perform some function, the call will cause the test to be run
and will then return the status.

Some tests require that the processor will not complete within the system specific period. These are
termed partitioned tests and a complete test will take more than one call to startCbit to complete.
Therefore, when the call is made a test will be specified to be either:

- COMPLETE - the call will complete within one startCbit invocation. The caller shall be blocked
until the test is finished. The OS may pre-empt this.

- PARTITIONED – the call will not complete within one startCbit invocation. The OS shall not pre-
empt it.

- The startCbit call returns bit_test_status which can be set to one of three values:

- PASSED – the specified test has completed within the last startCbit invocation,

- ONGOING – the specified test is PARTITIONED and has not completed within the last
startCbit invocation,

- FAILED – the specified test has failed within the last startCbit invocation.

If the call returns bit_test_status as FAILED, the service getCbitResult is used to retrieve the detailed
failure information for the last test to fail.

If the startCbit call is made with the test code of zero, the CBIT software will perform all tests in a
round-robin manner. In this case the call will always be set to PARTITIONED and will always set
bit_test_status as ONGOING until a failure is detected. The next invocation of startCbit, after a call
returns bit_test_status as FAILED, will recommence testing at the next test in the round-robin
sequence.

The service returns SUCCESS if CBIT is invoked correctly, otherwise it returns ERROR.

Parameter Description:

test_code

DataType Definition unsigned long

Description This is an integer value which identifies which CBIT test to run. If the code is zero the
complete set of tests is run in a cyclic fashion.

Domain Values No special values are associated with this parameter.

mode

DataType Definition CbitModeType

Description This allows the caller to specify the method to use to run a test - either to completion
or in a series of defined sections called slices.

Domain Values No special values are associated with this parameter.

bit_test_status

NATO UNCLASSIFIED 301

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DataType Definition BitTestStatus

Description This specifies the status of the Bit call.

PASSED signifies that the test has completed and passed within the last startCbit
invocation.

ONGOING – the specified test is PARTITIONED and has not completed within the
last startCbit invocation.

FAILED – the specified test has failed within the last startCbit invocation

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- getCbitResult.

11.7.6.3 getCbitResult

Purpose:

Get the Continuous Built In Test result.

Syntax:

ReturnStatus getCbitResult (
out CbitResult cbit_result );
Description:

This service shall get the latest available complete CBIT result. It conveys the CBIT result as provided
by the MSL at the MOS interface.

An ‘ERROR’ condition shall be returned when the retrieval of the CBIT result from the MSL has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

cbit_result

Data Type Definition CbitResult

Description The CBIT result

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The CBIT has been performed.

Associated Calls:

NATO UNCLASSIFIED 302

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

None

11.7.6.4 startIbit

Purpose:

Start The Initiated Built In Test.

Syntax:

ReturnStatus startIbit();
Description:

This service shall start the IBIT. The OS replies this request to start the IBIT at MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of starting the IBIT has
failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

- getIbitResult.

11.7.6.5 getIbitResult

Purpose:

Get the Initiated Built In Test result.

Syntax:

ReturnStatus getIbitResult (
out IbitResult ibit_result );
Description:

This service shall get the IBIT result. It conveys the IBIT result as provided by the MSL at the MOS
interface.

An ‘ERROR’ condition shall be returned when the retrieval of the IBIT result from the MSL has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

ibit_result

NATO UNCLASSIFIED 303

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition IbitResult

Description The IBIT result

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The IBIT has been performed.

Associated Calls:

- startIbit.

11.7.7 CFM Information Services

11.7.7.1 getMyCfmStatus

Purpose:

Get the Status of the CFM.

Syntax:

ReturnStatus getMyCfmStatus (
out CfmStatus cfm_status );
Description:

This service shall get the status of the Module on which it is executed.

The OS replies this request to get the CFM Status at MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of getting the CFM Status
has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

cfm_status

Data Type Definition CfmStatus

Description The status of the CFM

Domain Values All value of the enum type CfmStatus.

Prerequisite Conditions:

None

Associated Calls:

None

NATO UNCLASSIFIED 304

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

11.7.7.2 getMyCfmInfo

Purpose:

Get the characteristics of the CFM.

Syntax:

ReturnStatus getMyCfmInfo (
out CfmInfo cfm_info );
Description:

This service shall get the characteristics of the Module on which it is executed.

This information is static. Therefore, when this service is called, the OS may not necessarily reply this
request to get the CFM Info at MOS interface. It may be done once at initialisation time.

An ‘ERROR’ condition shall be returned when the request at MOS interface of getting the CFM Info
has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

cfm_info

Data Type Definition CfmInfo

Description The characteristics of the CFM

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None

11.7.7.3 getMyPeId

Purpose:

Get the identifier of the PE.

Syntax:

ReturnStatus getMyPeId (
out PublicId my_pe_id );
Description:

This service shall get the identifier of the PE on which it is executed.

This information is static. Therefore, when this service is called, the OS may not necessarily reply this
request to get the PE Resources at MOS interface. It may be done once at initialisation time.

NATO UNCLASSIFIED 305

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

An ‘ERROR’ condition shall be returned when the request at MOS interface of getting the PE
Resources has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

my_pe_id

Data Type Definition PublicId

Description The identifier of the PE

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- getMyCfmInfo.

11.7.8 CFM Resources Management Services

11.7.8.1 requestDownloadToCfm

Purpose:

Request the download of data to a remote CFM.

Syntax:

TimedReturnStatus requestDownloadToCfm (
in CfmDescription remoteCfm ) ;
Description:

This service shall be used to request an MLI download to a remote CFM. The data to be transferred is
stored in a file on an MMM.

The transfer between the requesting CFM, on which the service is executed, and the remote CFM
may differently be performed depending on whether:

The file is stored on requesting CFM. The service shall send the data in using the MLI protocol.

The file is not stored on the requesting CFM. The requesting CFM shall send first the description of
the download to the CFM, hosting the data in a file, in using the OLI protocol, which at its turn, shall
send the data in using the MLI protocol.

The download is described in the structure CfmDescription that comprises:

- The type of download channel (DownloadChannelType): MLI or OLI_THEN_MLI.

The description of the communication channel (DownloadChannel) to be used depends on the type of
download:

NATO UNCLASSIFIED 306

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- In case of an MLI Download, the sending TC and the receiving TC (MliChannel),

- In case of an OLI_THEN_MLI download the sending VC and the receiving VC for the OLI part and
the sending TC and the receiving TC for the MLI part (OliMliChannel),

- The type of download (DownloadType), which specifies the type of data to be transferred. This
information leads the choice of the type of MLI message to be used,

- The information that is related to the type of data to be downloaded (DownloadDescription) and
that shall be used to build the payload message for the MLI transfer,

- The time-out value for processing this CFM for this download.

In case of an OLI_THEN_MLI transfer, the OS shall use the OLI message Remote MLI File Download
to send the description of the download to a remote MMM. The OS shall comply with the OLI
requirements. For more detail, refer to section 12.4.2.3.2.1.

In case of an MLI transfer, the OS shall build the payload part of the MLI Message and then use the
MOS interface to manage the MLI transfer protocol (request and reply). The corresponding MLI
Message to the Download type is described in the table below.

Table 30 – MLI Download Types

Download Type MLI Request MLI Reply

IMAGE_DOWNLOAD Load Image Load Image Acknowledge

RTGTABLE_DOWNLOAD Load Routing Table Load Routing Table Acknowledge

TIME_DOWNLOAD Load Time Configuration Load Time Configuration Acknowledge

NETWORK_DOWNLOAD Load Network Configuration Load Network Configuration Acknowledge

POWER_DOWNLOAD Load Power Switches Configuration Load Power Switches Configuration Acknowledge

For more detail, refer to section 12.7 MLI.

This service is blocking and is released when the transfer is complete successfully or in a failure.

An ‘TM_ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with another one or invalid comparing its
expected value by the OS,

- Although the input structure is valid the OS is not able to complete the service due to
unavailability of resources that are required for this download,

- The protocol of the communication means (OLI or MLI) has failed.

An ‘TM_TIMEOUT’ condition shall be returned when the download has not been performed in the
required time.

The service shall return ‘TM_SUCCESS’ on successful completion.

Parameter Description:

cfmDescription

NATO UNCLASSIFIED 307

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition CfmDescription

Description The proprieties of the CFM download

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

All communication means have previously been configured.

Associated Calls:

None

11.7.8.2 getRemoteInfo

Purpose:

Get information from a remote CFM.

Syntax:

TimedReturnStatus getRemoteInfo (
in RemoteServiceId serviceid ,
in CfmMliChannel mliChannel ,
in InputLocalParameters input_buffer ,
in unsigned long input_length ,
out OutputRemoteParameters output_buffer ,
in unsigned long output_max_length ,
out unsigned long output_actual_length ) ;
Description:

This service shall be used to get information from a remote CFM.

The OS shall retrieve this information by using the MLI protocol.

The corresponding MLI Message to the RemoteServiceId is described in the table below.

RemoteServiceId MLI Request MLI Reply

PBIT_RESULT Request PBIT Result Reply PBIT Result

CFM_STATUS Request CFM Status Reply CFM Status

CFM_INFO Request CFM Info Reply CFM Info

TEST_MESSAGE Test Message Test Message Acknowledge

START_IBIT Request IBIT Start Reply IBIT Start

IBIT_RESULT Request IBIT Result Reply IBIT Result

NETWORK_STATUS Request Network Status Reply Network Status

POWER_STATUS Request Power Switches Status Reply Power Switches Status

NATO UNCLASSIFIED 308

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

For more detail, refer to section 12.7 MLI.

The GSM provides a parameter input_buffer with the input parameters that are copied in the MLI
request message. The input parameters depend on the MLI message and may not exist. See section
12.7 MLI and description of InputLocalParameters structure.

The GSM provides the output_max_length of the OutputRemoteParameters as an input

parameter and retrieves the output_actual_length as output parameter. The output parameters
depend on the MLI message and may not exist. See section 12.7 MLI and description of
OutputRemote Parameters structure

This service is blocking and is released when the transfer is complete successfully or in a failure.

An ‘TM_ERROR’ condition shall be returned when:

- At least one element of the input structure is inconsistent with an other one or invalid comparing
its expected value by the OS,

- Although the input structure is valid the service has not completed due to unavailability of
resources at or MSL level,

- The MLI protocol has failed,

- An ‘TM_TIMEOUT’ condition shall be returned when the information has not been retrieved in the
required time.

The service shall return ‘TM_SUCCESS’ on successful completion.

Parameter Description:

service_id

Data Type Definition RemoteServiceId

Description Description of the remote service Id

Domain Values No special values are associated with this parameter.

mliChannel

Data Type Definition CfmMliChannel

Description Information on the MLI channel for accessing a CFM.

Domain Values No special values are associated with this parameter.

input_buffer

Data Type Definition InputLocalParameters

Description Description of input parameters associated to a remote service Id

Domain Values No special values are associated with this parameter.

input_length

NATO UNCLASSIFIED 309

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition Length

Description Length in bytes of the input parameters

Domain Values No limitation for this service

output_buffer

Data Type Definition OutputLocalParameters

Description Description of output parameters associated to a remote service Id

Domain Values No special values are associated with this parameter.

output_max_length

Data Type Definition Length

Description Maximum length in bytes of the output parameters

Domain Values No limitation for this service

output_actual_length

Data Type Definition Length

Description Actual length in bytes of the output parameters

Domain Values No limitation for this service

Prerequisite Conditions:

TC’s for the MLI have previously been configured.

Associated Calls:

None

11.7.9 Time Configuration Services

11.7.9.1 configureClock

Purpose:

Configure the clock mode of the Module.

Syntax:

ReturnStatus configureClock (
in ClockInfo clock_info ) ;
Description:

The service shall be used to configure the mode of the clock of the Module. The OS replies this
request to configure the clock mode at MOS interface.

NATO UNCLASSIFIED 310

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

An ‘ERROR’ condition shall be returned when the request at MOS interface of configuring the clock
mode has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

clock_info

Data Type Definition ClockInfo

Description It describes the properties of a module local clock.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- attachFederatedClock.

11.7.9.2 attachFederatedClock

Purpose:

Attach a federated clock to the Module clock.

Syntax:

ReturnStatus attachFederatedClock (
in FederatedClockInfo federated_clock_info );
Description:

The service shall be used to attach a federated clock to the Module clock. The OS replies this
attachment at MOS interface.

An ‘ERROR’ condition shall be returned when the request at MOS interface of attachment has failed.

The service shall return ‘SUCCESS’ on successful completion.

Parameter Description:

federated_clock_info

Data Type Definition FederatedClockInfo

Description This structure provides the properties of a federated clock.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

The Federated Clock is not attached

NATO UNCLASSIFIED 311

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Associated Calls:

- configureClock.

11.7.10 Logging Management Services

11.7.10.1 readLog

Purpose:

This service allows the GSM to read a message through the OS from the local log.

Syntax:

ResourceReturnStatus readLog (
in LogMessageType message_type ,
in unsigned long log_id ,
out CharacterSequence log_message );
Description:

This service is used by the GSM to read a message from a location in a specific log. The
message_type identifies the message log that is being read from. The log_id identifies the location
within that log from where the message will be read. Log_id is unique to a message_type. A log_id of
Null will read from the end of the particular log.

This service returns RS_SUCCESS if the message is successfully read. If the service does not read
successfully, RS_RESOURCE is returned if there are resource limitations, such as the log not being
found or not being available, otherwise it shall return RS_ERROR.

Parameter Description:

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

log_id

Data Type Definition Unsigned long

Description This parameter identifies where the message is to be read from memory of a
particular log.

Domain Values Null if the message is to be read from the end of a message log.

log_message

Data Type Definition CharacterSequence

Description The sequence of characters that is read.

NATO UNCLASSIFIED 312

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values A NUL character terminates the message.

Prerequisite Conditions:

None.

Associated Calls:

- writeLog.

11.7.10.2 writeLog

Purpose:

This service allows the GSM to write a message to a device.

Syntax:

ResourceReturnStatus writeLog (
in LogMessageType message_type ,
in unsigned long log_id ,
in CharacterSequence log_message );
Description:

This service is used by the GSM to write the message in the parameter log_message through to the
OS for subsequent writing to a device. The message_type identifies which message log is being
written to. The log_id identifies the location in memory within that log. If a null is given as the log_Id
then the OS shall append the message to the specified log. Log_id is unique to a message_type.

This service returns RS_SUCCESS if the message is written successfully. If the service fails to
successfully write the message it shall return RS_RESOURCE if there are resource limitations such
as the log is full, not found or not available; otherwise it shall return RS_ERROR.

Parameter Description:

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

log_id

Data Type Definition Unsigned long

Description This parameter identifies where the message is to be written to in a particular log.

Domain Values Null if the message is to be written to the end of a particular message log.

log_message

Data Type Definition CharacterSequence

NATO UNCLASSIFIED 313

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The sequence of characters that is written.

Domain Values A NUL character terminates the message.

Prerequisite Conditions:

None.

Associated Calls:

- logMessage,

- getLogReport,

- writeLogDevice.

11.7.10.3 getLogReport

Purpose:

This service is used to retrieve a message from an application thread.

Syntax:

TimedReturnStatus getLogReport (
out CharacterSequence log_message ,
out LogMessageType message_type ,
out PublicId process_id ,
in TimeInterval timeout );
Description:

This service shall block the caller until the OS receives a log message or the timeout occurs. The
Fault Management uses the parameter message_type to identify error messages, which are used in
fault localisation. The parameter process_id provides the identifier of the process, which has logged
the message. The call shall return TM_ERROR if service has not been performed properly,
TM_TIMEOUT if the call times out, otherwise it shall return TM_SUCCESS.

Parameter Description:

log_message

Data Type Definition CharacterSequence

Description The sequence of characters to be written.

Domain Values A NUL character terminates the message.

message_type

Data Type Definition LogMessageType

Description This parameter identifies the message as being one of four types.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 314

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

process_id

Data Type Definition PublicId

Description The identifier of the process that has logged the message.

Domain Values No special values are associated with this parameter.

timeout

Data Type Definition TimeInterval

Description The timeout parameter defines the maximum time a thread shall wait for receiving a
message.

Domain Values Zero TimeInterval

This specifies a non-blocking condition. The service returns immediately if there is no

message waiting.

Infinite TimeInterval

This specifies an unbounded waiting for a log message.

Prerequisite Conditions:

None.

Associated Calls:

- logMessage,

- writeLog,

- writeLogDevice,

- SMOS services.

NATO UNCLASSIFIED 315

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12 Logical Interfaces Definitions

Note: The parameter descriptions, which are provided with the service specifications, provides the
reference to the data type (see section 13.5), the meaning of the parameter and, if applicable,
additions or restrictions of the domain values.

12.4 OLI

12.4.1 VC Header
The VC Header shall contain the VC ID that is the VC Identifier.

It shall conform to the general format illustrated in Figure 65, below.

VC ID VC Data

4 Bytes m Bytes

Figure 65 - General VC Message Format

12.4.2 OLI Services

The scheme used to transport OLI service messages shall involve inserting the message contents in
to the payload of a VC (VC) message. VC shall be specified as OLI VC by means of the blueprints
information associated with the VC.

12.4.2.1 OLI Protocol

This section covers general and specific protocol requirements for individual OLI services. It also
outlines the particular usage of each OLI service.

12.4.2.1.1 General Protocol Features

The protocol used for the various OLI services outlined in this specification relies on a
REQUEST/RESPONSE transaction i.e. for every service request there is an associated response.
The behaviour of the OLI manager in any PE shall conform to the requirements in the following
sections. These requirements are common for all services (those specific to a given service are dealt
with in section 12.4.2.1.2).

12.4.2.1.1.1 Service Request Management

All OLI services rely on a REQUEST/RESPONSE protocol to carry out data or control transactions.

The OLI management in the CFM initiating the request and a timer started shall record the
transmission of any OLI service request message, uniquely identified by a Transfer ID value (see
section 12.4.2.1.1.1). If the response associated with the previously transmitted request is received
with the same Transfer ID value as the request and within the expiry time of the timer (above), the
record of the initial request shall be deleted, the associated response timer stopped and notification of
the arrival of the response sent to the original requesting entity.

NATO UNCLASSIFIED 316

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

If no response to the initiating request is received before the timer expires (see section 12.4.2.1.1.3).
The record of the original request shall be deleted and notification of the timer expiry event (an error
condition) delivered to the original requesting entity.

If a response to the initiating request is received but the Transfer ID value does not match that of the
initiating request message, it shall be treated as an unsolicited service response (see section
12.4.2.1.1.2) and handled accordingly.

12.4.2.1.1.2 Unsolicited Service Response Handling

If an OLI service response is received for which there exists no record of the corresponding service
request initiation (see section 12.4.2.1.1.2), the PE receiving this message shall release all associated
resources (discard the message) and report an OS error.

12.4.2.1.1.3 Response Timers

Response timers are used as a means of recovering from the condition, whereby a PE requesting an
OLI service receives no associated service response. The time after which the PE requesting the
service deems that no response has been received (the response timer expiry) shall be determined
by the anticipated ability of the PE's in the given system to respond to such a request.

12.4.2.1.2 Specific Service Protocol Requirements

This section deals with protocol requirements specific to the usage of the individual services listed
here. In this section the following terms are used to denote specific entities within the system:

- MMM/PE. This represents a PE on an MMM with a direct file access, which receives OLI request,

- CFM/PE. This represents a remote PE in the ASAAC system that sends OLI request.

In each case where special requirements are detailed in relation to particular services, the behaviour
outlined indicates how the entity supporting the service is required to carry out the associated action.

12.4.2.1.2.1 File Reading

The basic protocol relating to this services dictates that REQUEST messages propagate from a
CFM/PE to a MMM/PE destination. Similarly, the basic protocol also dictates that REPLY messages
propagate from a MMM/PE source to CFM/PE destination.

The CFM/PE shall choose the download method. It shall download the file either:

- In one request, the size of the amount data to be read shall be the size of the file and the offset
null or

- In several requests, in this case the fragmentation shall be entirely managed by the requesting
CFM/PE.

This is illustrated in the diagram in Figure 66 below.

12.4.2.1.2.1.1 Request Read File

This is a request type service and shall be used in CFM/PE to MMM/PE transactions only.

NATO UNCLASSIFIED 317

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.4.2.1.2.1.2 Reply Read File

This is a reply type service and shall be used in MMM/PE to CFM/PE transactions only.

C as e 1 : Com plete F ile

C FM/PE/OS reading within one transf er MMM/PE/OS
Size = F ile Size
Off s et = 0

R EQUEST R EAD FILE

REPLY READ F ILE

Cas e 2 : 8 Kby tes F ile

reading within three trans f ers

R EQU EST READ F ILE

REPLY READ F ILE

1s t Transf er :
Size = 3 Kby tes
Of f set = 0
R EQU EST READ F ILE

REPLY READ F ILE

2nd Trans fer :

Size = 3 Kby tes
Off s et = 3 Kby tes

R EQU EST READ F ILE

REPLY READ F ILE

3rd Trans fer :

Size = 2 Kby tes
Off s et = 6 Kby tes

Figure 66 - File Reading Protocol

12.4.2.1.2.1.3 Error Handling

Following the receiving status of each transaction shall be:

- READ_FILE_ACK_OK: no error, it shall be returned after a successful download,

- READ_FILE_ACK_FAILURE_NO_FILE: the transaction has failed, the file has not been found,

- READ_FILE_ACK_FAILURE_NO_READ_ACCESS: the transaction has failed, the read access to

the file has been denied.

12.4.2.1.2.2 Remote MLI File Download

The basic protocol relating to this services dictates that REQUEST messages propagate from a
CFM/PE to a MMM/PE destination. Similarly, the basic protocol also dictates that REPLY messages
propagate from a MMM/PE source to CFM/PE destination.

The targeted actor of the MLI download differs following the requested MLI service. For more
information refer to the MLI specification.

This is illustrated in the diagram in Figure 67, below.

NATO UNCLASSIFIED 318

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.4.2.1.2.2.1 Request Remote MLI File Download

This is a request type service and shall be used in CFM/PE to MMM/PE transactions only.

12.4.2.1.2.2.2 Reply Remote MLI File Download

This is a reply type service and shall be used in MMM/PE to CFM/PE transactions only. This REPLY
message is sent at the end of the MLI transaction.

CFM/PE/OS MMM/PE/OS Targeted Actor

REQUEST MLI FILE DOWNLOAD

MLI DOWNLOAD

MLI DOWNLOAD ACKNOWLEDGE

MLI DOWNLOAD

MLI DOWNLOAD ACKNOWLEDGE

REPLY MLI FILE DOWNLOAD

Figure 67 - Remote MLI Download Management Protocol

12.4.2.1.2.2.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

- RET_LOAD_IMAGE_ACK_IMAGE_LOAD_OK: no error, it shall be returned after a successful

and complete image download,

- RET_LOAD_IMAGE_ACK_FAILURE_ALREADY_LOADED: the transfer is aborted and the status

is returned at upper level,

- RET_LOAD_IMAGE_ACK_FAILURE_UNKNOWN_FORMAT: the transfer is aborted and the

status is returned at upper level,

- RET_LOAD_IMAGE_ACK_FAILURE_INSUFFICIENT_RESOURCES: the transfer is aborted and

the status is returned at upper level,

- RET_LOAD_IMAGE_ACK_UNKNOWN_ERROR: the transfer is aborted and the status is

returned at upper level.

12.4.2.2 OLI Services Message Structure

The data type OliMessage (see section 13.5) defines the OLI message structure.

NATO UNCLASSIFIED 319

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.4.2.3 OLI Services Features

Table 31 - OLI Services

Request Reply Section

File Reading 12.4.2.1.2.1

Request Read File Reply Read File

Remote MLI File Download 12.4.2.1.2.2

Request Remote MLI File Download Reply Remote MLI File Download

12.4.2.3.1 File Reading

The following services are required to enable one PE to download a file from a remote PE, the
contents of which are specified in a dedicated message field.

12.4.2.3.1.1 Request Read File

RequestFileReadPayload

Data Type Definition struct RequestFileReadPayload {

unsigned long size ;
unsigned long offset ;
CharacterSequence filename ;
};
Description This message shall be transmitted when issuing a request to load the file specified in
the message.

Size:

The size, in bytes, of the amount data to be read.

Offset:

The offset in bytes, relative to the Start-of-File. When a fragmented transfer is

performed, the offset shall be computed according to the actual size of the previous
fragment transfer

Filename:

ASCII string compliant to the targeted file access management. The string shall be
NUL terminated.

Domain Values No special values are associated with this parameter.

12.4.2.3.1.2 Reply Read File

ReplyFileReadPayload

Data Type Definition struct ReplyFileReadPayload {

NATO UNCLASSIFIED 320

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReplyFileReadPayload

unsigned long size ;

unsigned long checksum ;
ReadFileResult result ;
OctetSequence filedata;
};
Description This message shall be transmitted as an acknowledgement of a request to load a file.
It contains a status element as notification of its ability to carry out the command.

Size:

The actual size, in bytes, of read data.

Checksum:

32-bit checksum value of all the bytes contained in the File data field

Result:

Notification of the success or the nature of the failure of the File Reading process.

File data:

Data for the file transferred in this message.

Domain Values No special values are associated with this parameter.

12.4.2.3.2 Remote MLI File Download

The following services are required to enable one PE to request the download of a file by a MMM/PE
via MLI to a remote CFM, the contents of which are specified in a dedicated message field.

12.4.2.3.2.1 Request Remote MLI File Download

RequestRemoteMliDownload

Data Type Definition struct RequestRemoteMliDownload {

CfmDescription cfm_description ;
};
Description This message shall be transmitted when issuing a request a MMM/PE to load a file
on a CFM.

CFM description:

All necessary information to initiate a file download by a remote PE

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 321

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.4.2.3.2.2 Reply Remote MLI Image Download

ReplyRemoteMliDownload

Data Type Definition struct ReplyRemoteMliDownload {

unsigned long block_number ;
LoadFileResult result ;
};
Description This message shall be transmitted as an acknowledgement of a request to load a file.
This is the acknowledgement that the remote PE has performed the actual download
via MLI. It contains a status element as notification of its ability to carry out the
command.

Block number:

The block number is either the total number of fragments that make up the complete
image if the transfer has succeeded or, if the transfer has failed, the fragment index of
the last fragment that has been sent.

Result:

Notification of the success or the nature of the failure of the image loading process.

Domain Values No special values are associated with this parameter.

12.5 GLI

The GLI Interface is a logical interface for synchronisation of GSM functions. The structure of the
System Management function is described in section 9.4.1 of this document.

12.5.1 GLI Representation

The GLI interface shall be implemented using VC’s. (Refer to section 9.5). It allows GSM functions
within the system management hierarchy to communicate between different levels of the System
Management Hierarchy.

12.5.2 GLI Services

GLI Services cover the following functions

- Coordination of a Configuration / Reconfiguration process between GSM hierarchy levels,

- Module Management,

- Health Monitoring of sub-ordinate GSM levels,

- Security Management Configuration,

- Key Management.

Table 32 provides an overview of the GLI services. In the sender and receiver columns, the prefixes
super- and sub- mean respectively super-ordinate and subordinate.

NATO UNCLASSIFIED 322

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table 32 - GLI Services List

GLI Message Sender Receiver Description

Load_Configuration super-CM sub-CM Request to load a new configuration.

Configuration_Loaded Acknowledge the loading of the requested

sub-CM super-CM
configuration.

Stop_Configuration Request to suspend the execution of Application

super-CM sub-CM
Processes.

Configuration_Stopped Acknowledge that Application Processes have

sub-CM super-CM
acquired ‘STOPPED’ status.

Run_Configuration Request to start / resume execution of Application

super-CM sub-CM
Processes.

Configuration_Running Acknowledge that Application Processes have

sub-CM super-CM
acquired ‘RUNNING’ status.

Change_Configuration super-CM sub-CM Request to change the configuration.

Configuration_Changed sub-CM super-CM Acknowledge a new configuration status.

Request_New_CFM sub-CM super-CM Request for a spare CFM

New_CFM_Allocated super-CM sub-CM Give the id of a spare CFM

Deallocate_CFM sub-CM super-CM Request to deallocate a previously allocated CFM

CFM_Deallocated Acknowledge that the requested CFM has been

super-CM sub-CM
deallocated

Request_BIT_Result super-FM sub-FM Query the result of the most recent BIT.

Report_BIT_Result Retrieve the result of the requested BIT and report

sub-FM super-FM
it.

Fault_Report sub-FM super-HM Pass on fault handling.

Are_You_Alive super-HM sub-HM Query function identification and status.

I_Am_Alive sub-HM super-HM Acknowledge function identification and status.

RequestSC Request the SM IA to create a secure connection

sub-SM super-SM
with it.

SCResponse super-SM sub-SM Notifies the SM RE of the validity of its request.

DH_Send_M sub-SM super-SM These dialogue messages are used in order to

determine a common synchronous encryption key
DH_Send_X super-SM sub-SM using the Diffie Helman technique.

DH_Send_XimodM sub-SM super-SM

DH_Send_XjmodM super-SM sub-SM

NATO UNCLASSIFIED 323

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

GLI Message Sender Receiver Description

RequestKey sub-SM super-SM Requests an encrypted encryption key.

SendKey super-SM sub-SM Sends the requested encrypted encryption key.

12.5.2.1 GLI Message Structure

Every GLI message consists of a GLI Service identifier and some parameters.

The data type GliMessage (Refer to chapter 8) describes the GLI message structure.

12.5.2.2 Configuration / Reconfiguration Process

12.5.2.2.1 Load_Configuration

Purpose:

Request to load a new configuration.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Load_Configuration config_to_be_loaded

Description:

The super-ordinate Configuration Management Function requests from a Configuration Management

function directly sub-ordinate to itself to acquire a configuration. The configuration change at the sub-
ordinate level is additive, i.e. the base configuration at the sub-ordinate level is not destroyed.

The sub-ordinate Configuration Management function shall on this request completely re-build the
configuration, which is identified by the parameter config_to_be_loaded.

Parameter Description:

config_to_be_loaded

Data Type Definition PublicId

Description This parameter identifies the configuration to be acquired.

Domain Values config_to_be_loaded < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated services:

NATO UNCLASSIFIED 324

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Configuration_Loaded.

12.5.2.2.2 Configuration_Loaded

Purpose:

Acknowledge the loading of the requested configuration.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Configuration_Loaded config_loaded

Description:

The sub-ordinate Configuration Management Function acknowledges to a Configuration Management

function directly super-ordinate to itself that a configuration has been acquired. This configuration is
identified by the parameter config_loaded.

If the sub-ordinate Configuration Management Function has encountered an error in the process of
acquiring the requested configuration it shall indicate this fact by a value 0xFFFFFFFF for the
parameter config_loaded.

Parameter Description:

config_loaded

Data Type Definition PublicId

Description This parameter identifies the configuration that has been acquired by the
acknowledging Configuration Management function.

Domain Values 0xFFFFFFFF indicates an error that has occurred when loading the configuration.

Prerequisite Conditions:

None

Associated services:

- Load_Configuration.

12.5.2.2.3 Stop_Configuration

Purpose:

Request to suspend the execution of Application Processes.

VC Message Layout:

GLI Service GLI Service

NATO UNCLASSIFIED 325

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ID Parameters

4 bytes 4 bytes

Stop_Configuration config_to_be_acquired

Description:

The super-ordinate Configuration Management Function requests from a Configuration Management

function directly sub-ordinate to itself to transfer all Application Processes into ‘STOPPED’ state. The
configuration, which is associated with the status to be acquired, is identified by the parameter
config_to_be_acquired.

Parameter Description:

config_to_be_acquired

Data Type Definition PublicId

Description This parameter identifies the configuration to be acquired.

Domain Values config_to_be_acquired < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

- Configuration_Stopped.

12.5.2.2.4 Configuration_Stopped

Purpose:

Acknowledge that Application Processes have acquired ‘STOPPED’ status.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Configuration_Stopped config_acquired

Description:

The sub-ordinate Configuration Management Function acknowledges to a Configuration Management

function directly super-ordinate to itself that Application Processes have been transferred into
‘STOPPED’ state. The actually acquired configuration is identified by parameter config_acquired.

If the sub-ordinate Configuration Management Function has encountered an error in the process of
suspending application execution the requested configuration it shall indicate this fact by a value
0xFFFFFFFF for the parameter config_acquired.

Parameter Description:

NATO UNCLASSIFIED 326

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

config_acquired

Data Type Definition PublicId

Description This parameter identifies the configuration that has been acquired by the
acknowledging Configuration Management function.

Domain Values 0xFFFFFFFF indicates an error that has occurred when loading the configuration.

Prerequisite Conditions:

None

Associated Calls:

- Stop_Configuration.

12.5.2.2.5 Run_Configuration

Purpose:

Request to start / resume the execution of Application Processes.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Run_Configuration config_to_be_run

Description:

The super-ordinate Configuration Management Function requests from a Configuration Management

function directly sub-ordinate to itself to transfer all Application Processes into ‘RUNNING’ state. The
configuration, which is associated with the status to be acquired, is identified by the parameter
config_to_be_run.

Parameter Description:

config_to_be_run

Data Type Definition PublicId

Description This parameter identifies the configuration to be acquired.

Domain Values config_to_be_run < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

- Configuration_Running.

NATO UNCLASSIFIED 327

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.5.2.2.6 Configuration_Running

Purpose:

Acknowledge that Application Processes have acquired ‘RUNNING’ status.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Configuration_Running config_run

Description:

The sub-ordinate Configuration Management Function acknowledges to a Configuration Management

function directly super-ordinate to itself that Application Processes have been transferred into
‘RUNNING’ state. The actually acquired configuration is identified by parameter config_run.

If the sub-ordinate Configuration Management Function has encountered an error in the process of
resuming application execution the requested configuration it shall indicate this fact by a value
0xFFFFFFFF for the parameter config_run.

Parameter Description:

config_run

Data Type Definition PublicId

Description This parameter identifies the configuration that has been acquired by the
acknowledging Configuration Management function.

Domain Values 0xFFFFFFFF indicates an error that has occurred when loading the configuration.

Prerequisite Conditions:

None

Associated Calls:

- Run_Configuration.

12.5.2.2.7 Change_Configuration

Purpose:

Request to change the configuration.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

NATO UNCLASSIFIED 328

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Change_Configuration configuration_event

Description:

The super-ordinate Configuration Management Function requests from a Configuration Management

function directly sub-ordinate to itself to transfer its configuration into another status. This transition is
specified by the parameter configuration_event.

The transition triggered by configuration_event shall be implemented by an action list (Refer to

section 11.6.1.3).

Parameter Description:

configuration_event

Data Type Definition PublicId

Description This parameter identifies an event that is related to the current configuration status of
the sub-ordinate Configuration Management Function and identifies a transition into
another configuration status..

Domain Values configuration_event < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

- Configuration_Changed.

12.5.2.2.8 Configuration_Changed

Purpose:

Acknowledge a new configuration status.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Configuration_Changed new_configuration

Description:

The sub-ordinate Configuration Management Function acknowledges to a Configuration Management

function directly super-ordinate to itself that a configuration state transition has been completed. The
new configuration is identified by the parameter new_configuration.

If the sub-ordinate Configuration Management Function has encountered an error in the process of
acquiring the requested configuration it shall indicate this fact by a value 0xFFFFFFFF for the
parameter new_configuration.

Parameter Description:

NATO UNCLASSIFIED 329

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

new_configuration

Data Type Definition PublicId

Description This parameter identifies the configuration that has been acquired by the
acknowledging Configuration Management function.

Domain Values 0xFFFFFFFF indicates an error that has occurred when loading the configuration.

Prerequisite Conditions:

None

Associated Calls:

- Change_Configuration.

12.5.2.3 Module Management

12.5.2.3.1 Request_New_CFM

Purpose:

Request for a spare CFM

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 0 bytes

Request_New_CFM -

Description:

The sub-ordinate Configuration Management Function requests from a Configuration Management

function directly super-ordinate to itself to allocate a spare CFM.

Parameter Description:

None

Prerequisite Conditions:

None

Associated Calls:

- New_CFM_Allocated

12.5.2.3.2 New_CFM_Allocated

Purpose:

NATO UNCLASSIFIED 330

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Give the id of a spare CFM

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

New_CFM_Allocated Allocated_Cfm_id

Description:

The super-ordinate Configuration Management Function acknowledges to a Configuration

Management function directly sub-ordinate to itself that a spare CFM has been allocated and can be
used to restore a service. This CFM is identified by the parameter cfm_id.

If the super-ordinate Configuration Management Function has encountered an error in the process of
allocating a CFM, it shall indicate this fact by a value 0xFFFFFFFF for the parameter cfm_id.

Parameter Description:

Allocated_Cfm_id

Data Type Definition PublicId

Description This parameter identifies the CFM that has been allocated by the acknowledging
Configuration Management function.

Domain Values 0xFFFFFFFF indicates an error that has occurred when allocating a spare CFM.

Prerequisite Conditions:

The receiver of this message has requested for a spare CFM.

Associated Calls:

- Request_New_CFM.

12.5.2.3.3 Deallocate_CFM

Purpose:

Request to deallocate a previously allocated CFM

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Deallocate_CFM Deallocate_Cfm_id

Description:

NATO UNCLASSIFIED 331

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The sub-ordinate Configuration Management Function requests from a Configuration Management

function directly super-ordinate to itself to deallocate a CFM. This CFM is specified by the parameter
Deallocate_Cfm_Id.

Parameter Description:

Deallocate_Cfm_Id

Data Type Definition PublicId

Description This parameter identifies a CFM which the sub-ordinate Configuration Management
Function wants to release.

Domain Values Deallocate_Cfm_id < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

- CFM_Deallocated.

12.5.2.3.4 CFM_Deallocated

Purpose:

Acknowledge that the requested CFM has been deallocated

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

CFM_Deallocated Deallocated_Cfm_id

Description:

The super-ordinate Configuration Management Function acknowledges to a Configuration

Management function directly sub-ordinate to itself that a CFM has been deallocated, this CFM
becoming a spare one. The CFM is identified by the parameter cfm_id.

If the super-ordinate Configuration Management Function has encountered an error in the process of
deallocating the requested CFM it shall indicate this fact by a value 0xFFFFFFFF for the parameter
cfm_id.

Parameter Description:

Deallocated_Cfm_id

Data Type Definition PublicId

Description This parameter identifies the deallocated CFM already acquired by the sub-ordinate
Configuration Management function.

NATO UNCLASSIFIED 332

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values 0xFFFFFFFF indicates an error that has occurred when deallocating the CFM.

Prerequisite Conditions:

The receiver of this message has requested to deallocate the CFM identified by the parameter.

Associated Calls:

- Deallocate_CFM.

12.5.2.4 Health Monitoring / Fault Management

A Health Monitoring Function above the lowest level, which is the Resource Element level, is
collecting three types of health status information from the sub-ordinate GSM functions:

- If the sub-ordinate level GSM Function is not able to localise and mask a fault, a fault report is
passed on to the immediately super-ordinate level Health Monitoring function.

- Every Integration Area level or aircraft level Health Monitoring Function is periodically querying
the health of all of its immediately sub-ordinate GSM functions by issuing an Are_You_Alive
message. The sub-ordinate level is responding with an I_Am_Alive message.

- The super-ordinate Fault Management function may retrieve BIT results of the sub-ordinate GSM
functions in order to build a system health view for ITM or fault localisation purposes.

To restart applications or services which have encountered problems, or for any system design
reason (load balancing, redundancy policies, etc.), a Fault Management Function may want to
retrieve spare CFM’s to load and run software on them.

A CFM can be reused once applications or services running on it are correctly terminated. A Fault
Management Function may want to release the CFM and reinsert it in the pool of spare CFM’s. The
deallocated CFM becomes a spare one that can be used by other Fault Management Functions.

For a given Fault Management Function, the Fault Management Function directly super-ordinate
handles the spare CFM’s it can retrieve.

12.5.2.4.1 Fault_Report

Purpose:

Pass on fault handling.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes See FaultReport

Fault_Report the_fault

Description:

The sub-ordinate Fault Management Function being not able to handle a fault completely within its
scope passes a fault handling on to the Health Monitoring function directly super-ordinate to itself.

NATO UNCLASSIFIED 333

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The fault report of the sub-ordinate Fault Management function is specified by the parameter
the_fault.

Parameter Description:

the_fault

Data Type Definition FaultReport

Description This parameter collects all information about a fault that was collected by the
reporting GSM function so far.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

None.

12.5.2.4.2 Are_You_Alive

Purpose:

Query function identification and status.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes 4 bytes

Are_You_Alive function_id_expected status_id_expected

Description:

The super-ordinate Health Monitoring Function requests from a GSM function directly sub-ordinate to
itself to identify it and to confirm its configuration status.

The expected function identifier of the quested GSM Function is provided by the parameter
function_id_expected. The expected status is provided by the parameter status_id_expected. The
latter parameter applies only for the sub-ordinate Configuration Management function.

The Are_You_Alive message shall be used periodically by the super-ordinate Health Monitoring
function to confirm the availability and status of any sub-ordinate GSM function.

Parameter Description:

function_id_expected

Data Type Definition PublicId

Description This parameter specifies the expected identity of the queried GSM function.

NATO UNCLASSIFIED 334

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values function_id_expected < 0xFFFFFFFF

For the definition of the values for this parameter refer to section 6.4.1.2.

status_id_expected

Data Type Definition PublicId

Description This parameter identifies the expected configuration status of the queried GSM
function.

Domain Values This status identifier applies only to the Configuration Management function. In case
a Configuration Management function is not included, the value of this parameter
shall be 0xFFFFFFFF.

Prerequisite Conditions:

None

Associated Calls:

- I_Am_Alive.

12.5.2.4.3 I_Am_Alive

Purpose:

Acknowledge function identification and status.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes 4 bytes

I_Am_Alive function_id_returned status_id_returned

Description:

The Are_You_Alive message shall be used periodically by the super-ordinate Health Monitoring
function to confirm the availability and status of any sub-ordinate GSM function.

The sub-ordinate GSM Function responds to the Are_You_Alive request received from the Health
Monitoring function directly super-ordinate to itself by providing its actual identification and its actual
configuration status.

If the expected function identification complies with the actual one the expected function identification
shall be acknowledged by the parameter function_id_returned. If the queried GSM function is not
available or the expected function identification does not comply function_id_returned shall provide
the value 0xFFFFFFFF.

If the expected status complies with the actual one the expected status shall be acknowledged by the
parameter status_id_returned. If the queried GSM function is not available or the expected status
does not comply status_id_returned shall provide the value 0xFFFFFFFF.

Parameter Description:

NATO UNCLASSIFIED 335

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Function_id_returned

Data Type Definition PublicId

Description This parameter provides the actual identity of the queried GSM function.

Domain Values function_id_expected = 0xFFFFFFFF

This means that the queried function is not available.

Status_id_returned

Data Type Definition PublicId

Description This parameter provides the actual configuration status of the queried GSM function.

Domain Values This status identifier applies only to the Configuration Management function. In case
a Configuration Management function is not included, the value of this parameter
shall be 0xFFFFFFFF.

Prerequisite Conditions:

None

Associated Calls:

- Are_You_Alive.

12.5.2.4.4 Request_BIT_Result

Purpose:

Query the result of the last recent BIT

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Request_BIT_Result type

Description:

The super-ordinate Fault Management Function requests from a Fault Management function directly
sub-ordinate to itself to retrieve the result of the most recent BIT whose type is specified by the
parameter bit_type.

Parameter Description:

type

Data Type Definition BitType

NATO UNCLASSIFIED 336

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description This parameter identifies the type of the BIT that the requesting Fault Management
function wants to retrieve the result.

Domain Values No special values are associated with this parameter.

Prerequisite Conditions:

None

Associated Calls:

- Report_BIT_Result.

12.5.2.4.5 Report_BIT_Result

Purpose:

Retrieve the result of the requested BIT and report it.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes Refer to data type definition of BitResult

Report_BIT_Result result

Description:

The sub-ordinate Fault Management function reports to the Fault Management function directly super-
ordinate to itself the result of the most recent BIT whose type has been identified by the request.

If the sub-ordinate Fault Management function is not able to retrieve the result, it shall signal the
problem by setting the result of the BIT as erroneous according to SMOS BIT definitions.

Parameter Description:

result

Data Type Definition BitResult

Description This parameter provides identifies the CFM that has been allocated by the
acknowledging Fault Management function.

Domain Values If BIT result retrieval is not possible, the sub-ordinate Fault Management Function
shall signal it by using appropriate BIT result values as defined by SMOS BIT
definitions.

Prerequisite Conditions:

The receiver of this message has requested for a BIT result.

Associated Calls:

- Request_BIT_Result.

NATO UNCLASSIFIED 337

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.5.2.5 Security Management

12.5.2.5.1 RequestSC

Purpose:

Used to request the implementation of a secure communications link between two instances of GSM
security manager.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

RequestSC TlsId

Description:

This service is used by a subordinate GSM-SM in order to request the implementation of a secure
communications link between itself and its superordinate GSM-SM. The purpose of this secure link is
to enable the superordinate GSM-SM to distribute encryption/authentication keys to its underlying
subordinate GSM-SM's in a secure manner.

Parameter Description:

TlsId

Data Type Definition PublicId

Description The identification of the TLS upon which the calling GSM-SM is hosted.

Domain Values > 0.

Prerequisite Conditions:

None

Associated Calls:

- SCResponse.

12.5.2.5.2 SCResponse

Purpose:

Notifies the SM RE of the validity of its request.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

NATO UNCLASSIFIED 338

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

SCResponse Response

Description:

This command is issued by a superordinate GSM-SM in response to the receipt of the RequestSC
command. Once the GSM-SM has determined whether a secure communications link can be
implemented between the requesting GSM-SM and itself, it uses this command to notify the
requesting GSM-SM of its decision.

Parameter Description:

Response

Data Type Definition Boolean

Description ASAAC_TRUE indicates the request was successfulASAAC_FALSE indicates that

the request was rejected.

Domain Values No special values are associated with this parameter, implementation dependent.

Prerequisite Conditions:

This command can only be issued in response to receiving the RequestCR command.

Associated Calls:

- RequestCR.

12.5.2.5.3 DH_Send_M

Purpose:

The message is the first message in a four-message dialogue between participating GSM-SM's in
which the Diffie-Helman algorithm is performed.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

DH_Send_M key

Description:

Implementation dependent.

Parameter Description:

key

Data Type Definition unsigned long

Description An interim value used to determine the common key.

NATO UNCLASSIFIED 339

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values >0

Prerequisite Conditions:

This message can only be sent if the response to the earlier request to establish a secure
communications link was successful.

Associated Calls:

- DH_Send_X,

- DH_Send_XimodM,

- DH_Send_XjmodM.

12.5.2.5.4 DH_Send_X

Purpose:

This is the second message in a four message dialogue between participating GSM-SM's in which the
Diffie-Helman algorithm is performed.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

DH_Send_X key

Description:

Implementation dependent.

Parameter Description:

key

Data Type Definition unsigned long

Description An interim value used to determine the common key.

Domain Values >0

Prerequisite Conditions:

This message can only be sent in response to having received DH_Send_M.

Associated Calls:

- DH_Send_M,

- DH_Send_XimodM,

- DH_Send_XjmodM.

NATO UNCLASSIFIED 340

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.5.2.5.5 DH_Send_XimodM

Purpose:

This message is the third message in a four-message dialogue between participating GSM-SM’s in
which the Diffie-Helman algorithm is performed.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

DH_Send_XimodM key

Description:

Implementation dependent.

Parameter Description:

key

Data Type Definition unsigned long

Description An interim value used to determine the common key.

Domain Values >0

Prerequisite Conditions:

This message can only be sent in response to having received DH_Send_X.

Associated Calls:

- DH_Send_M,

- DH_Send_X,

- DH_Send_XjmodM.

12.5.2.5.6 DH_Send_XjmodM

Purpose:

This message is the fourth message in a four-message dialogue between participating GSM-SM’s in
which the Diffie-Helman algorithm is performed.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

NATO UNCLASSIFIED 341

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DH_Send_XjmodM key

Description:

Implementation dependent.

Parameter Description:

key

Data Type Definition unsigned long

Description An interim value used to determine the common key.

Domain Values >0

Prerequisite Conditions:

This message can only be sent in response to having received DH_Send_XimodM.

Associated Calls:

- DH_Send_M,

- DH_Send_X,

- DH_Send_XimodM.

12.5.2.5.7 Request_Key

Purpose:

Request an encrypted encryption key.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 4 bytes

Request_Key TlsId

Description:

This message is used by a subordinate GSM-SM to request that its superordinate GSM-SM send it
the encryption/authentication keys that it requires in order to encrypt/decrypt/authenticate the
messages sent to the functional Application Processes hosted on the TLS upon which it is
responsible.

Parameter Description:

Tls_Id

Data Type Definition PublicId

NATO UNCLASSIFIED 342

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The identification of the TLS upon which the calling GSM-SM is hosted.

Domain Values >0

Prerequisite Conditions:

None

Associated Calls:

- Send_Key.

12.5.2.5.8 Send_Key

Purpose:

Sends the requested encrypted encryption key.

VC Message Layout:

GLI Service GLI Service

ID Parameters

4 bytes 40 bytes

Send_Key key_array

Description:

This message is used by the super-ordinate GSM-SM to send the encryption/authentication keys to
the subordinate GSM-SM that requested them.

Parameter Description:

key_array

Data Type Definition unsigned long key_array[ 10 ]

Description A 10 element array containing the encryption/decryption keys to be used by the GSM-
SM.

Domain Values Each element containing a key should be >0.

Prerequisite Conditions:

This message can only be sent in response to having received Request_Key.

Associated Calls:

- Request_Key.

12.6 SMLI

The SMLI Interface is a logical interface for synchronisation of system management functions. The
System Management functions separated into two parts:

NATO UNCLASSIFIED 343

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- AM: Functionality developed for a specific programme in mind and located above the APOS
within the AL.

- GSM: Functionality that is applicable to all IMA systems and located below the APOS within the
OSL.

12.6.1 SMLI Representation

The SMLI interface shall be implemented using VC’s. (Refer to section 9.5.1.2). It only allows system
management functional acting at the same level within the system management hierarchy to
communicate with each other.

12.6.2 SMLI Services

As already mentioned, the purpose of the SMLI is to provide synchronisation and control between the
Application and GSM functions during system initialisation (for the Security management functions)
and subsequent system configuration and reconfiguration.

Reconfiguration in IMA systems can be instigated due to either:

- Mission mode changes in response to aircrew requests during normal operation,

- The Fault Management process in response to the detection of faults occurring within the system.

In the case of mission mode changes, it is the AM that requests a change in configuration to its
corresponding GSM, while in the case of the Fault Management process it is the GSM that notifies the
AM of its desire to change mode. This would then allow the AM to notify the aircrew (through cockpit
display functional applications, for example) of the intended change of mode.

These dialogues are defined in 12.6.2.

Table 33 - SMLI Services List

SMLI Service Sender Receiver Description

Request_Lc_Change AM GSM A request to reconfigure the system/Integration Area from

the logical configuration to one identified by the
parameter. See 12.6.2.2.1

Lc_Changed GSM AM Notification that the system/Integration Area has been

reconfigured as requested. See 12.6.2.2.2

Signal_For_Lc_Change GSM AM A message to signal the intent to reconfigure the

system/Integration. See 12.6.2.3.1

Ready_For_Lc_Change AM GSM Notification that the applications have been prepared in

readiness for the reconfiguration change. See 12.6.2.3.2

Security_Data_Written AM GSM Permission to proceed with the instantiation of the

Security Management hierarchy. See 12.6.2.4.1

SM_Config_Complete GSM AM Notification that the Security Management hierarchy has

been instantiated. See 12.6.2.4.2

Distant_Error_Event GSM AM Handle remote error. See 12.6.2.5.1

NATO UNCLASSIFIED 344

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.6.2.1 SMLI Message Structure

The following sections outline the proposed SMLI services and the format of the SMLI messages,
which are transported as the payload of a VC message. In each case they shall conform to the
general format illustrated in Figure 68 below:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Figure 68 - General SMLI Message Format

SMLI Service ID identifies the SMLI service required.

SMLI Service Parameter provides an identifier, which is interpreted by the addressee of the SMLI
message (the security management SMLI services do not make use of this parameter). For the SMLI
message definition refer to the data type SmliMessage (see section 13.5).

The individual values are defined in the individual service subsections.

12.6.2.2 Acquire System Mode

The AM may require the logical configuration of the application to be changed. In order to do this it
must ask the GSM to perform a logical configuration change. The Request_Lc_Change message is
provided for this purpose. This message shall be used by the AM to request the corresponding GSM
Function to change the Logical Configuration due to the mission progress, a pilot decision or any
other reason from functional applications side. When the logical configuration has been changed the
Lc_Changed message is used by the GSM to inform the AM that the requested change has been
completed.

12.6.2.2.1 Request_Lc_Change

Purpose:

Application Request for Change of Logical Configuration

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Request_Lc_Change event_id

Description:

The AM function sending the SMLI message ‘Request_Lc_Change’ specifies an event identifier
event_id. The receipt of this message shall trigger a reconfiguration into a new Logical Configuration.

The value of the event identifier is common to both AM and GSM.

Parameter Description:

NATO UNCLASSIFIED 345

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

event_id

Data Type Definition PublicId

Description This parameter provides an event triggering a specific reconfiguration process being
performed.

Domain Values event_id < 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

- Lc_Changed.

12.6.2.2.2 Lc_Changed

Purpose:

Acknowledge the Change of Logical Configuration.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Lc_Changed logical_config_id

Description:

GSM shall send this SMLI message to the AM in response to the SMLI message
‘Request_Lc_Change’. The parameter logical_config_id shall provide the identifier for the current
Logical Configuration of the GSM instance, which is associated to the receiving AM function.

In case that no valid logical configuration could be acquired, e.g. due to an error in the reconfiguration
process, the value of logical_config_id shall be set to 0xFFFFFFFF.

Parameter Description:

logical_config_id

Data Type Definition PublicId

Description This parameter provides an identifier for a Logical Configuration.

Domain Values The value of the parameter is either:

The id of the requested logical configuration,

The id of a degraded version of the requested configuration or 0xFFFFFFFF.

Indicating that there was an error during the reconfiguration process.

NATO UNCLASSIFIED 346

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Prerequisite Conditions:

‘Request_Lc_Change’ SMLI message has been sent to the GSM.

GSM has successfully reconfigured into a new Logical Configuration.

Associated Calls:

- Request_Lc_Change.

12.6.2.3 Acquire Degraded Mode

In the event of an error, the GSM can trigger the transition from a Logical Configuration into another
one. As the aircraft functions, represented by Application Processes may require some
reconfiguration, e.g. the shutdown of some non-core equipment, GSM can synchronise the
reconfiguration of AM with its own reconfiguration. It signals the new Logical Configuration to AM with
the SMLI message ‘Signal_For_Lc_Change’, AM reconfigures and acknowledges the completion
of its reconfiguration to GSM by means of the service ‘Ready_For_Lc_Change’. Then the GSM
starts its reconfiguration.

12.6.2.3.1 Signal_For_Lc_Change

Purpose:

Notify AM about a forthcoming change of Logical Configuration.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Signal_For_Lc_Change logical_config_id

Description:

GSM requests 'AM' to synchronise with a forthcoming change of Logical Configuration. AM is

expected to prepare for the Logical Configuration, which is identified by the parameter
logical_config_id.

Parameter Description:

logical_config_id

Data Type Definition PublicId

Description This parameter provides the identifier of a Logical Configuration.

Domain Values Less than 0xFFFFFFFF

Prerequisite Conditions:

None

Associated Calls:

NATO UNCLASSIFIED 347

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- Ready_For_Lc_Change.

12.6.2.3.2 Ready_For_Lc_Change

Purpose:

Notify GSM that Application Functions are prepared for the change of Logical Configuration.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Ready_For_Lc_Change event_id

Description:

AM acknowledges to GSM that it has prepared for the change of Logical Configuration, which is
specified by the parameter event_id. This message is sent by the AM in response to the reception of
a Signal_For_Lc_Change SMLI message. As AM is the final point of decision on a change of
logical configuration, this decision not necessarily complies with the GSM request. Therefore, AM
replies with an event identifier in order to trigger the actual change of logical configuration.

In case the AM was not able to prepare for the new Logical Configuration or an error has occurred in
the reconfiguration process the value of event_id shall be set to 0xFFFFFFFF.

Parameter Description:

event_id

Data Type Definition PublicId

Description This parameter provides an event triggering a specific reconfiguration process being
performed.

Domain Values event_id < 0xFFFFFFFF

Prerequisite Conditions:

‘Signal_For_Lc_Change’ SMLI message has been sent by GSM.

AM has successfully prepared for a change of Logical Configuration.

Associated Calls:

- Signal_For_Lc_Change.

12.6.2.4 Initialisation of Security Management

12.6.2.4.1 Security_Data_Written

Purpose:

NATO UNCLASSIFIED 348

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Used to synchronise the security aspects of system initialisation.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Security_Data_Written 0x00000000 (Padding)

Description:

The security aspects of system initialisation require the Application Security Management function to:

- Receive mission data being uploaded to the system,

- Decrypt the mission data,

- Write the decrypted mission data to the secure database.

In order to simplify the overall system initialisation process, it is important that this functionality is
completed prior to the GSM Security Management hierarchy being instantiated and the
encryption/decryption keys being transferred onto the PE's on which they are to be hosted.
Consequently, this service is used by the Application Security Manager to notify the AC level GSM
Security Management function that this functionality has been completed and that it is now ok for it to
proceed with its aspects of security related system initialisation.

Parameter Description:

None.

Prerequisite Conditions:

None.

Associated Calls:

- SM_Config_Complete.

12.6.2.4.2 SM_Config_Complete

Purpose:

Used to synchronise the security aspects of system initialisation.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

SM_Config_Complete 0x00000000 (Padding)

NATO UNCLASSIFIED 349

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description:

This service is used by the AC level GSM Security Management function to inform the Application
Security Manager that it has instantiated the Security Management Hierarchy and that all the
encryption/decryption keys have been copied to the RE level GSM-SM’s that are to use them during
the mission.

Parameter Description:

None.

Prerequisite Conditions:

The GSM-SM must have completed its functionality in response to it receiving the SMLI Security Data
Written command.

Associated Calls:

- Security Data Written.

12.6.2.5 Handle Remote Error

The system management hierarchy is partitioning the aircraft system into Integration Areas. These
protect the configuration of an integration area from reconfigurations of remote integration areas.
However, on top of the reconfiguration there may be still a dependency on application level, which
shall be managed by AM. In the case of an error within an IA it may be necessary to inform the AM in
order to perform any required action that will affect parts of the application beyond the IA boundary.

12.6.2.5.1 Distant_Error_Event

Purpose:

Indicate a change of Logical Configuration due to a Fault Masking Reconfiguration.

VC Message Layout:

SMLI Service SMLI Service

ID Parameter

4 bytes 4 bytes

Distant_Error_Event logical_config_id

Description:

GSM indicates to AM that the Logical Configuration of an Integration Area has been changed due to a
fault recovering reconfiguration in that Integration Area. The parameter logical_config_id identifies the
logical configuration, which has been acquired by the Integration Area, which has initiated this SMLI
message.

In case this fault recovery has failed, sending a 0xFFFFFFFF value with the parameter
logical_config_id indicates this.

Parameter Description:

logical_config_id

NATO UNCLASSIFIED 350

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data Type Definition PublicId

Description This parameter provides the identifier of a Logical Configuration.

Domain Values 0xFFFFFFFF is indicating that there is no valid Logical Configuration. Otherwise less
than 0xFFFFFFFF.

Prerequisite Conditions:

The GSM of an Integration Area has changed its Logical Configuration due to handling a fault.

Associated Calls:

None

12.7 MLI

12.7.1 TC Header
The TC Header shall contain the TC ID that is the TC Identifier. In each case it shall conform to the
general format illustrated in Figure 69, below.

TC ID TC Data

4 Bytes m Bytes

Figure 69 - General TC Message Format

12.7.2 MLI Services

12.7.2.1 MLI Message Structure

The following sections outline the proposed MLI services and the format of the MLI messages, which
are, in turn, transported in the payload of a TC message. In each case they shall conform to the
general format illustrated in Figure 70, below.

Optional Header
MLI Service ID Header Length Data Length Transfer ID Parameters MLI Data

4 Bytes 4 Bytes 4 Bytes 4 Bytes x Bytes m Bytes

Figure 70 - General MLI Message Format

MLI Service ID identifies the MLI service required. These values are defined in the individual service
subsections.

Header Length determines the total length of the header information fields.

Data Length determines the total length of the MLI data field.

NATO UNCLASSIFIED 351

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Optional Element Optional Element Optional Element

Identifier Length Data

4 bytes 4 bytes m bytes

X m

Figure 71 - Optional Parameter Element Format

The Optional Header Parameters are additional information fields specific to MLI messages included
for flexibility and are organised in such a way as to avoid making the format of the Optional Header
Parameters field difficult to expand as requirements grow for the contents of an MLI message. The
overall Optional Header Parameters field may, if used, be composed of any number of Optional
Parameter Elements, the format of which is shown in Figure 71.

The Optional Element Identifier uniquely identifies the type of information present in the Optional
Element data field. The Optional Element Length field specifies the length of the Optional Element
data field. The Optional Element data field contains the specific Optional Parameter information (one
example, to satisfy a potential future requirements, might be Quality of Service related data).

The Transfer ID field uniquely identifies the transaction taking place between any two MLI service
users. Transfer ID is either a counter or a random value. The requirement is the reply message shall
return the Transfer ID of the request message.

The MLI data field refers to the data associated with the MLI service identified by the MLI Service ID
field.

All parameters shall be arranged in multiples of 4 bytes in length and encoded in a ‘Big-Endian’ format
i.e. the MSB is transmitted first.

In the following sections, if a particular message has associated MLI Payload data, then the contents
of the individual fields, which are concatenated to form the payload of the message, are itemised in
the accompanying table. The order in which the MLI message payload fields are transmitted shall
conform to the order in which they are listed in the relevant table.

12.7.2.2 MLI Services List

Table 34 - MLI Services

Request Reply Section

CFM Resources Management Services 12.7.2.2.1

Request PBIT Result Reply PBIT Result 12.7.2.2.1.1

Request CFM Status Reply CFM Status 12.7.2.2.1.2

Request CFM Info Reply CFM Info 12.7.2.2.1.2

Test Message Test Message Acknowledge 12.7.2.2.1.4

Request IBIT Start Reply IBIT start acknowledge 12.7.2.2.1.5

Request IBIT Result Reply IBIT Result 12.7.2.2.1.6

NATO UNCLASSIFIED 352

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Request Reply Section

Download Management Services 12.7.2.2.1.5

Load Image Load Image Acknowledge 12.7.2.2.2.1

Load Routing Table Load Routing Table Acknowledge 12.7.2.2.2.2

Time Management Services 12.7.2.2.3

Load Time Configuration Load Time Configuration Acknowledge 12.7.2.2.3.1

Request AGT Reply AGT 12.7.2.2.3.2

Ready for ALT Synchro Start ALT Synchro 12.7.2.2.3.3

Request ALT Reply ALT 12.7.2.2.3.4

Request AGT ALT Reply AGT ALT 12.7.2.2.3.5

Network Management Services 12.7.2.2.4

Load Network Configuration Load Network Configuration Acknowledge 12.7.2.2.4.1

Request Network Status Reply Network Status 12.7.2.2.4.2

Power Switches Management Services 12.7.2.2.5

Load Power Switches Configuration Load Power Switches Configuration Acknowledge 12.7.2.2.5.1

Request Power Switches Status Reply Power Switches Status 12.7.2.2.5.2

12.7.2.2.1 CFM Resources Management Services

This subsection covers all services associated with the management of CFM resources.

12.7.2.2.1.1 PBIT Information Transfer

The following services are required to enable one CFM to interrogate a remote CFM for the results of
its PBIT cycle.

12.7.2.2.1.1.1 Request_PBIT_Result

This message shall be transmitted when requesting a CFM to report the result of its PBIT cycle. The
format for this message shall be as shown in Figure 72, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

NATO UNCLASSIFIED 353

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

00000010H 16 0 x

Figure 72 - Request PBIT Result Format

No additional information elements are required in this message.

12.7.2.2.1.1.2 Reply_PBIT_Result

This message shall be transmitted when responding to a request to report the result of its PBIT cycle.
The format for this message shall be as shown in Figure 73, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000011H 16 (See Table 35) x See Table 35

Figure 73 - Reply PBIT Result Format

The MLI Message Payload fields shall be encoded as follows.

Table 35 - Reply PBIT Status Payload Field Definition

Field 1 – PBIT Pass/Fail

Description Overall result of module PBIT cycle – set to PASS only if all PBIT tests pass.

Field Length 4 Bytes

Domain Values PBIT_RESULT_PASS = 00H,

PBIT_IN_PROGRESS = 10H,

PBIT_NOT_AVAILABLE = 20H,

PBIT_RESULT_FAIL = FFH.

Field 2 - PBIT Result Information

Description Detailed inventory of PBIT test results

Field Length Refer to PBIT result data type.

Domain Values Refer to PBIT result data type.

12.7.2.2.1.2 CFM Status Transfer

The following services are required to enable one CFM to interrogate a remote CFM for its current
status.

NATO UNCLASSIFIED 354

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.1.2.1 Request_CFM_Status

This message shall be transmitted when requesting a CFM to report its current operational status.
The format for this message shall be as shown in Figure 74, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000020H 16 0 x

Figure 74 - Request CFM Status Format

No additional information elements are required in this message.

12.7.2.2.1.2.2 Reply_CFM_Status

This message shall be transmitted when responding to a request to a CFM to report its operational
status. The CFM Status differs whether the CFM conforms to generic CFM model or not.

The format for this message shall be as shown in Figure 75, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000021H 16 (See Table 36) x See Table 36

Figure 75 - Reply CFM Status Format

The MLI Message Payload field shall be encoded as follows.

Table 36 - Reply CFM Status Payload Field Definition

Field 1 – CFM Type

Description Attribute defining the type of CFM to which the corresponding CFM type-specific
information applies.

Field Length 4 Bytes

Domain Values GENERIC_CFM = 00H

NOT_GENERIC_CFM = FFH

Fields 2 to N – CFM Type-Specific Information

NATO UNCLASSIFIED 355

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Inventory of the status of the resources present in the CFM, the type of which is specified
in Field 1. The type attribute determines how the contents of the subsequent data fields
are to be interpreted.

Field Length Dependent upon CFM Type/Architecture.

Domain Values CFM Type Dependent

If CFM Type (Field 1) = GENERIC_CFM, see Table 37

If CFM Type (Field 1) = NOT_GENERIC_CFM, see Section Table 38

For all CFM’s, which conform to the GENERIC_CFM type, the following table (Table 37) applies. It
represents the extension to the “Reply_CFM_Status” message payload specific to this CFM type.

Table 37 - GENERIC_CFM Specific Extension to Payload Information

Field 1 – Consolidated CFM Status

Description Current module operational status.

Field Length 4 Bytes

Domain Values OK = 0H

FAILED = FH

NOT_AVAILABLE = 1H

IN_PROGRESS = 2H

Field 2 – Detailed MSB Status

Description Detailed current MSB operational status.

Field Length 4 Bytes

NATO UNCLASSIFIED 356

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values Bit-mapped code, encoded as follows:

Bit 3-0: PBIT

Bit 7-4: CBIT

Bit 11-8: IBIT

Bit 15-12: Routing Table Download

Bit 19-16: MSL Download

Domain value of each bit-mapped field (as above) is:

OK = 0H,

FAILED = FH,

NOT_AVAILABLE = 1H,

IN_PROGRESS = 2H

Field 3 – Number of PE’s

Description The number of PE’s within this CFM

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Detailed PE Status

Description List of records, showing the current operational status of all CFM PE’s.

Field Length X Bytes (dependent upon CFM resources/configuration). For each PE, a record of 8 Bytes
is assigned for this purpose.

Domain Values See below.

Record Field 1 (Field 4, Record N) - PE ID

Description The unique identifier, used to reference the individual PE, to that the status information in
the second field of a given record refers.

Field Length 4 Bytes

Domain Values 0…232-1

Record Field 2 (Field 4, Record N) – PE Status

Description Current PE operational status.

Field Length 4 Bytes

NATO UNCLASSIFIED 357

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values Bit-mapped code, encoded as follows:

Bit 3-0: PBIT

Bit 7-4: CBIT

Bit 11-8: IBIT

Bit 15-12: Routing Table Downloaded

Bit 19-16: MSL Downloaded

Bit 23-20: OS Downloaded

Bit 27-24: GSM Downloaded

Bit 31-28: RTBP Downloaded

Domain value of each bit-mapped field (as above) is;

OK = 0H,

FAILED = FH,

NOT_AVAILABLE = 1H,

IN_PROGRESS = 2H

For all CFM’s, which are NOT_GENERIC_CFM type, the following table (Table 38) applies. It
represents the extension to the “Reply_CFM_Status” message payload specific to this CFM type.

Table 38 - NOT_GENERIC_CFM Specific Extension to Payload Information

Field 1 – Consolidated CFM Status

Description Current module operational status.

Field Length 4 Bytes

Domain Values OK = 0H

FAILED = FH

NOT_AVAILABLE = 1H

IN_PROGRESS = 2H

12.7.2.2.1.3 CFM Information Transfer

The following services are required to enable one CFM to interrogate a remote CFM for general
configuration information.

NATO UNCLASSIFIED 358

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.1.3.1 Request_CFM_Info

This message shall be transmitted when requesting a CFM to report its module configuration
information. The format for this message shall be as shown in Figure 76, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000030H 16 0 x

Figure 76 - Request CFM Info Format

No additional information elements are required in this message.

12.7.2.2.1.3.2 Reply_CFM_Info

This message shall be transmitted when responding to a request to a CFM to its module configuration
information. The format for this message shall be as shown in Figure 77, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000031H 16 (See Table 39) x See Table 39

Figure 77 - Reply CFM Info Format

The MLI Message Payload fields shall be encoded as follows:

Table 39 - Reply CFM Info Payload Field Definition

Field 1 - CFM Info

Description CFM Information

Field Length Refer to CFM Info data type.

Domain Values Refer to CFM Info data type.

12.7.2.2.1.4 CFM Communication Test

The following services are required to enable one CFM to test that a physical communication path
between itself and a remote CFM is intact. The tested communication is between the requesting PU
and the end point.

The used TC selects the end point.

NATO UNCLASSIFIED 359

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.1.4.1 Test_Message

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000040H 16 0 x

Figure 78 - Test Message Format

This message shall be transmitted, if a CFM is required to determining the integrity of a ‘point-to-point’
connection between two CFM’s. The format for this message shall be as shown in Figure 78.

No additional information elements are required in this message. This message may also be used as
part of a scheme for gathering Quality of Service (QoS) information related to the network(s) over
which the message is transferred.

12.7.2.2.1.4.2 Test_Message_Acknowledge

This message shall be transmitted when acknowledging reception of a Test Message. If received by
the CFM issuing the original Test Message it is used to confirm the integrity of a ‘point-to-point’
connection between two CFM’s. The format for this message shall be as shown in Figure 79, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000041H 16 0 x

Figure 79 - Test Message Acknowledge Format

No additional information elements are required in this message.

12.7.2.2.1.5 IBIT Start Transfer

The following services are required to enable one CFM to request a remote CFM for starting its IBIT
cycle.

12.7.2.2.1.5.1 Request_IBIT_Start

This message shall be transmitted when requesting a CFM to start its IBIT cycle. The format for this
message shall be as shown in Figure 80, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

NATO UNCLASSIFIED 360

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000050H 16 0 x

Figure 80 - Request IBIT Start Format

No additional information elements are required in this message.

12.7.2.2.1.5.2 Reply_IBIT_Start

This message shall be transmitted when responding to a request to start its IBIT cycle. The format for
this message shall be as shown in Figure 81, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000051H 16 4 x See Table 40

Figure 81 - Reply IBIT Start Format

The MLI Message Payload fields shall be encoded as follows.

Table 40 - Reply IBIT Status Payload Field Definition

Field 1 – IBIT Start Result

Description Notification of the result of the IBIT start.

Field Length 4 Bytes

Domain Values OK = 00H

IN_PROGRESS = 1H

NOT_AVAILABLE = 2H

FAILED = FFH

12.7.2.2.1.6 IBIT Result Transfer

The following services are required to enable one CFM to interrogate a remote CFM for the results of
its IBIT cycle.

NATO UNCLASSIFIED 361

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.1.6.1 Request_IBIT_Result

This message shall be transmitted when requesting a CFM to report the result of its IBIT cycle. The
format for this message shall be as shown in Figure 82, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000060H 16 0 x

Figure 82 - Request IBIT Result Format

No additional information elements are required in this message.

12.7.2.2.1.6.2 Reply_IBIT_Result

This message shall be transmitted when responding to a request to report the result of its IBIT cycle.
The format for this message shall be as shown in Figure 83, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

00000061H 16 (See Table 41) x See Table 41

Figure 83 - Reply IBIT Result Format

The MLI Message Payload fields shall be encoded as follows.

Table 41 - Reply IBIT Result Payload Field Definition

Field 1 – IBIT Pass/Fail

Description Overall result of module IBIT cycle – set to PASS only if all IBIT tests pass.

Field Length 4 Bytes

Domain Values IBIT_RESULT_PASS = 00H

IBIT_IN_PROGRESS = 10H

IBIT_NOT_AVAILABLE = 20H

IBIT_RESULT_FAIL = FFH

NATO UNCLASSIFIED 362

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field 2 - IBIT Result Information

Description Detailed inventory of IBIT test results

Field Length Refer to IBIT result data type.

Domain Values Refer to IBIT result data type.

12.7.2.2.2 Download Management Services

This subsection covers all services associated with the management of downloading executable or
configuration data to a remote CFM.

12.7.2.2.2.1 Image Transfer

The following services are required to enable one CFM to download an image to a remote CFM, the
contents of which are specified in a dedicated message field.

12.7.2.2.2.1.1 Load_Image

This message shall be transmitted when issuing a request to load the Processing Element (PE)
specified in the message with a whole or fragment of a whole image. The format for this message
shall be as shown in Figure 84, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

01000000H 16 (See Table 42) x See Table 42

Figure 84 - Load Image Format

The MLI Message Payload fields shall be encoded as follows:

Table 42 - Load Image Payload Field Definition

Field 1 – PE ID

Description The unique identifier, used to reference the individual PE to which the image is to be
loaded.

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Image Content

Description Type of software items contained in the image.

NATO UNCLASSIFIED 363

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values Bit-mapped code, encoded as follows:

Bit 0 – MSL (0 = Absent, 1 = Present),

Bit 1 – OS (0 = Absent, 1 = Present),

Bit 2 – GSM (0 = Absent, 1 = Present),

Bit 3 – RTBP (0 = Absent, 1 = Present),

Bits 4 to 31 – UNUSED (Set to zero).

Field 3 – Load Instructions size

Description Size of flexible load instructions.

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Load Instructions

Description Notification to the image loader of specific image attributes e.g. image binary entry point,
image binary load address, image format, OS Type.

Field Length Defined in Field 3

Domain Values Hardware implementation dependent

Field 5 – Total Number of Blocks

Description The number of individual fragments of image data, which when reassembled, constitutes
a complete image.

Field Length 4 Bytes

Domain Values 1…232-1

Field 6 – Block Number

Description The sequentially numbered identifier of the image data fragment.

Field Length 4 Bytes

Domain Values 1…232-1

Field 7 – Image Size

Description The size, in bytes, of the overall image data when reassembled.

Field Length 4 Bytes

Domain Values 0…232-1

NATO UNCLASSIFIED 364

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field 8 – Fragment Size

Description The size, in bytes, of the image data fragment contained in this message. A fragment size
is multiple of 4.

Field Length 4 Bytes

Domain Values 0…232-1

Field 9 – Fragment Checksum

Description 32-bits checksum value of all the bytes contained in the Fragment Image data field (field
10 – see below).

Field Length 4 Bytes

Domain Values 0…232-1

Field 10 – Fragment Image Data

Description Data for the image fragment transferred in this message

Field Length Variable

Domain Values 0…232-1

12.7.2.2.2.1.2 Load_Image_Acknowledge

This message shall be transmitted as an acknowledgement of a request to load the Processing

Element (PE) specified in the message with a whole or fragment of a whole image. It contains a
status element as notification of its ability to carry out the command. The format for this message shall
be as shown in Figure 85, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

01000001H 16 (See Table 43) x See Table 43

Figure 85 - Load Image Acknowledge Format

The MLI Message Payload field shall be encoded as follows:

Table 43 - Load Image Acknowledge Payload Field Definition

Field 1 – PE ID

Description The unique identifier, used to reference the individual PE to which an attempt was made
to load the image.

Field Length 4 Bytes

NATO UNCLASSIFIED 365

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values 0…232-1

Field 2 – Image Content

Description Type of software items contained in the download image.

Field Length 4 Bytes

Domain Values Bit-mapped code, encoded as follows:

Bit 0 – MSL (0 = Absent, 1 = Present),

Bit 1 – OS (0 = Absent, 1 = Present),

Bit 2 – GSM (0 = Absent, 1 = Present),

Bit 3 – RTBP (0 = Absent, 1 = Present),

Bits 4 to 31 – UNUSED (Set to zero).

Field 3 – Total Number of Blocks

Description The number of individual fragments of image data, which when reassembled, constitutes
a complete image.

Field Length 4 Bytes

Domain Values 1…232-1

Field 4 – Block Number

Description The sequentially numbered identifier of the image data fragment received.

Field Length 4 Bytes

Domain Values 1…232-1

Field 5 – Load Image Result

Description Notification of the success or the nature of the failure of the image loading process.

Field Length 4 Bytes

Domain Values LOAD_IMAGE_ACK_LOAD_OK = OOH,

LOAD_IMAGE_ACK_FRAGMENT_LOAD_OK = 10H,

LOAD_IMAGE_ACK_FAILURE_ALREADY_LOADED = 20H,

LOAD_IMAGE_ACK_FAILURE_UNKNOWN_FORMAT = 30H,

LOAD_IMAGE_ACK_FAILURE_CHECKSUM_ERROR = 40H,

LOAD_IMAGE_ACK_FAILURE_INSUFFICIENT_RESOURCES = 50H,

LOAD_IMAGE_ACK_UNKNOWN _ERROR = 60H.

NATO UNCLASSIFIED 366

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.2.2 Routing Table Transfer

The following services are required to enable one CFM to download routing table data to a remote
CFM.

12.7.2.2.2.2.1 Load_Routing_Table

This message shall be transmitted when issuing a request to load the CFM with a routing table. The
format for this message shall be as shown in Figure 86, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

01000020H 16 (See Table 44) x See Table 44

Figure 86 - Load Routing Table Format

The MLI Message Payload fields shall be encoded as follows:

Table 44 - Load Routing Table Payload Field Definition

Field 1 – Total Number of Blocks

Description The number of individual fragments of the overall routing table data, which when
reassembled, constitute a complete routing table.

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the routing table data fragment.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Table Size

Description The size, in bytes, of the overall routing table data when reassembled.

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Fragment Size

Description The size, in bytes, of the routing table data fragment contained in this message. A
fragment size is multiple of 4.

NATO UNCLASSIFIED 367

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values 0…232-1

Field 5 – Fragment Checksum

Description 32-bits checksum value of all the bytes contained in the Fragment data field (field 6 – see
below).

Field Length 4 Bytes

Domain Values 0…232-1

Field 6 – Fragment Data

Description Data for the routing table fragment transferred in this message. The contents of the
routing table information (in its non-fragmented form) are defined in the tables below.

Field Length Variable (see Table 45)

Domain Values See Table 45

The following table represents the data common to all routing table information entries and defines
the type of routing configuration operation it is required to perform, based on the parameters
contained in the data fields, which follow it. The contents of the additional fields are defined in Table
46, Table 47 and Table 48. Note that there is no restriction on the information contained in the routing
information being of one exclusive type. The information fields shown in Table 45 are used to
distinguish one type of configuration information from another, but all three types of configuration
information would be expected to be present in a routing table configuration message.

Table 45 - Load Routing Table Data Definition

Field 1 – Configuration ID

Description The unique Identifier used to reference the type of configuration to perform

Field Length 4 Bytes

Domain Values CONFIGURE_INTERFACE = 0,

CONFIGURE_TRANSFER = 1,

CONFIGURE_PROTOCOL = 2,

DESTROY_TRANSFER = 3.

Field 2 – Configuration Data

Description Data for the specified configuration

Field Length Variable (see Table 46, Table 47 and Table 48)

Domain Values See Table 46, Table 47 and Table 48

NATO UNCLASSIFIED 368

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

As described in the previous table there are three types of configuration:

- CONFIGURE_INTERFACE which corresponds to the NII service ConfigureInterface,

- CONFIGURE_TRANSFER which corresponds to the NII service ConfigureTransfer,

- CONFIGURE_PROTOCOL which associates the requesting TC with the replying TC,

- DESTROY_TRANSFER, which corresponds to the NII service DestroyTransfer.

The configuration data defined in the following table (Table 46) represents the data encoding for
CONFIGURE_INTERFACE operations:

Table 46 - Data Definition for Interface Configuration

Field 1 – Interface ID

Description The unique and physical Identifier used to reference the interface within the CFM

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Network ID

Description The unique and logical Identifier used to reference the Network within the ASAAC System

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – Port ID

Description The unique and logical Identifier used to reference the Port within a Network

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Interface Type

Description The unique and hard coded Identifier used to reference the type of interface which is
dependant on the Network topology

Field Length 4 Bytes

Domain Values 0…232-1

Field 5 – Configuration Data Size

Description The size, in bytes, of the Configuration data.

Field Length 4 Bytes

NATO UNCLASSIFIED 369

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values 0…232-1

Field 6 – Configuration Data

Description Data for the specified interface configuration which is dependent on Network Technology

Field Length Variable

Domain Values 0…232-1

The configuration data defined in the following table (Table 47) represents the data encoding for
CONFIGURE_TRANSFER operations:

Table 47 - Data Definition for Transfer Configuration

Field 1 – TC ID

Description The unique Identifier used to reference the TC within the ASAAC System

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Network ID

Description The unique and logical Identifier used to reference the Network within the ASAAC System
which this TC is allocated

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – Port ID

Description The unique and logical Identifier used to reference the Port within a Network which this
TC is allocated

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Send / Receive

Description This defines the direction of data transfers on the TC, (as viewed from the CFM which is
on configuration).

Field Length 4 Bytes

Domain Values {SEND, RECEIVE}

Field 5 – Interface Type

Description This defines whether the TC is to be used for message or streaming transfers

NATO UNCLASSIFIED 370

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values {MESSAGE, STREAMING}

Field 6 – Interface Type

Description The unique and hard coded Identifier used to reference the type of interface where the TC
is transferred which is dependant on the Network topology

Field Length 4 Bytes

Domain Values 0…232-1

Field 7 – Configuration Data Size

Description The size, in bytes, of the Configuration data.

Field Length 4 Bytes

Domain Values 0…232-1

Field 8 – Configuration Data

Description Data for the specified interface configuration which is dependent on Network Technology

Field Length Variable

Domain Values 0…232-1

The configuration data defined in the following table (Table 48) represents the data encoding for
CONFIGURE_PROTOCOL operations:

Table 48 - Data Definition for Protocol Configuration

Field 1 – TC ID Request

Description The Identifier of the TC which will request the CFM which has been configured by this
message

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – TC ID Reply

Description The Identifier of the TC that is used to reply to the requesting TC.

Field Length 4 Bytes

Domain Values 0…232-1

NATO UNCLASSIFIED 371

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The configuration data defined in the following table (Table 49) represents the data encoding for
DESTROY_TRANSFER operations:

Table 49 - Data Definition for Destroy Transfer

Field 1 – TC ID

Description The unique Identifier used to reference the TC within the ASAAC System

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Network ID

Description The unique and logical Identifier used to reference the Network within the ASAAC System
which this TC is allocated

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – Port ID

Description The unique and logical Identifier used to reference the Port within a Network which this
TC is allocated

Field Length 4 Bytes

Domain Values 0…232-1

12.7.2.2.2.2.2 Load_Routing_Table_Acknowledge

This message shall be transmitted as an acknowledgement of a request to load a whole or fragment

of a whole routing table. It contains a status element as notification of its ability to carry out the
command. The format for this message shall be as shown in Figure 87, below:

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

01000021H 16 (See Table 50) x See Table 50

Figure 87 - Load Routing Table Acknowledge Format

The MLI Message Payload field shall be encoded as follows:

Table 50 - Load Routing Table Acknowledge Payload Field Definition

Field 1 – Total Number of Blocks

NATO UNCLASSIFIED 372

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The number of individual fragments of routing table data, which when reassembled,
constitutes a complete routing table.

Field Length 4 Bytes

Domain Values 1…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the routing table data fragment received.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Load Table Result

Description Notification of the success or the nature of the failure of the routing table fragment loading
process.

Field Length 4 Bytes

Domain Values LOAD_RTG_TABLE_ACK_CONFIGURATION_OK = 00H,

LOAD_RTG_TABLE_ACK_FRAGMENT_LOAD_OK = 10H,

LOAD_RTG_TABLE_ACK_FAIL_UNKNOWN_FORMAT = 20H,

LOAD_RTG_TABLE_ACK_FAIL_CHECKSUM_ERROR = 30H,

LOAD_RTG_TABLE_ACK_FAIL_RESOURCE_ASSIGNMENT = 40H,

LOAD_RTG_TABLE_ACK_UNKNOWN _ERROR = 50H.

12.7.2.2.3 Time Management Services

This subsection covers all services associated with the management of time distribution between
CFM’s or from external sources.

12.7.2.2.3.1 Time Configuration

The following services are required to enable one CFM to configure the Time Management to a
remote CFM.

12.7.2.2.3.1.1 Load_Time_Configuration

This message shall be transmitted when issuing a request to load the CFM with a time configuration.
The format for this message shall be as shown in Figure 88, below:

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID See Table 51

NATO UNCLASSIFIED 373

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000040H 16 (See Table 51) x

Figure 88 - Load Time Configuration Format

The MLI Message Payload fields shall be encoded as follows:

Table 51 - Load Time Configuration Payload Field Definition

Field 1 – Total Number of Blocks

Description The number of individual fragments of the overall time configuration table data, which
when reassembled, constitute a complete time configuration table.

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the time configuration table data fragment.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Table Size

Description The size, in bytes, of the overall time configuration table data when reassembled.

Field Length 4 Bytes

Domain Values 1…232-1

Field 4 – Fragment Size

Description The size, in bytes, of the time configuration table data fragment contained in this
message.

Field Length 4 Bytes

Domain Values 1…232-1

Field 5 – Fragment Checksum

Description 32-bit checksum value of all the bytes contained in the Fragment data field (field 6 – see
below).

Field Length 4 Bytes

Domain Values 0 .. 255

Field 6 – Fragment Data

NATO UNCLASSIFIED 374

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Data for the time configuration table fragment transferred in this message. The contents
of the time configuration table information (in its non-fragmented form) are defined in the
tables below.

Field Length Variable (see Table 52)

Domain Values See Table 52

The following table represents the data common to all time configuration information entries and
defines the type of time configuration operation it is required to perform, based on the parameters
contained in the data fields, which follow it. The contents of the additional fields are defined in Table
53 and Table 54. The information fields shown in Table 52 are used to distinguish one type of
configuration information from another. It is expected only one Clock Configuration. It may get either
none or one or several Federated Clock Configuration.

Table 52 - Load Time Configuration Data Definition

Field 1 – Configuration ID

Description The unique Identifier used to reference the type of configuration to perform

Field Length 4 Bytes

Domain Values CONFIGURE_CLOCK = 0

CONFIGURE_FEDERATED_CLOCK = 1

Field 2 – Configuration Data

Description Data for the specified configuration

Field Length Variable (see Table 53 and Table 54)

Domain Values See Table 53 and Table 54

As described in the previous table there are three types of configuration:

CONFIGURE_CLOCK which corresponds to the MOS service ConfigureClock

CONFIGURE_FEDERATED_CLOCK which corresponds to the MOS service

ConfigureFederatedClock

The configuration data defined in the following table (Table 53) represents the data encoding for
CONFIGURE_CLOCK operations:

Table 53 - Data Definition for Clock Configuration

Field 1 – Clock Mode

Description This type defines the different clock modes, which exist in the system.

Field Length 4 Bytes

NATO UNCLASSIFIED 375

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values MASTER_REFERENCE_CLOCK = 00H,

REFERENCE_CLOCK = 10H,

MODULE_CLOCK = 20H.

Field 2 – CLOCK ID

Description The unique and logical Identifier used to reference the clock within the ASAAC System

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – TC ID From Parent

Description The unique Identifier used to reference the TC within the ASAAC System which identifies
the CFM Parent sending TC

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – TC ID To Parent

Description The unique Identifier used to reference the TC within the ASAAC System which identifies
the CFM Parent receiving TC

Field Length 4 Bytes

Domain Values 0…232-1

Field 5 – SyncWavePeriod

Description The Clock synchronisation wave period

Field Length 8 Bytes. Refer to the TimeInterval Structure

Domain Values Refer to the TimeInterval Structure

Field 6 – MaxOfMissedALT

Description The Maximum number of allowed consecutively missing message

Field Length 4 Bytes

Domain Values 0…232-1

Field 7 – RangeforALT

Description The Acceptable range for the received ALT reference values

Field Length 8 Bytes. Refer to the TimeInterval Structure

Domain Values Refer to the TimeInterval Structure

NATO UNCLASSIFIED 376

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field 8 – ALTResBound

Description The ALT resolution bound

Field Length 8 Bytes. Refer to the TimeInterval Structure

Domain Values Refer to the TimeInterval Structure

Field 9 – MaxALTDiff

Description The Maximum bound for ALT time value difference

Field Length 8 Bytes. Refer to the TimeInterval Structure

Domain Values Refer to the TimeInterval Structure

Field 10 – TimeOut

Description Internal time between two “send request” before notifying an error

Field Length 8 Bytes. Refer to the TimeInterval Structure

Domain Values Refer to the TimeInterval Structure

The configuration data defined in the following table (Table 54) represents the data encoding for
CONFIGURE_FEDERATED_CLOCK operations:

Table 54 - Data Definition for Federated Clock Configuration

Field 1 – CLOCK ID

Description The unique and logical Identifier used to reference the clock within the ASAAC System

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – TC ID From Federated

Description The unique Identifier used to reference the TC within the ASAAC System which identifies
the CFM Federated sending TC

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – TC ID To Federated

Description The unique Identifier used to reference the TC within the ASAAC System which identifies
the CFM Federated receiving TC

Field Length 4 Bytes

NATO UNCLASSIFIED 377

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Domain Values 0…232-1

12.7.2.2.3.1.2 Load_Time_Configuration_Acknowledge

This message shall be transmitted as an acknowledgement of a request to load a whole or fragment

of a whole time configuration table. It contains a status element as notification of its ability to carry out
the command. The format for this message shall be as shown in Figure 89, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000041H 16 (See Table 55) x See Table 55

Figure 89 - Load Time Configuration Acknowledge Format

The MLI Message Payload field shall be encoded as follows.

Table 55 - Load Time Configuration Acknowledge Payload Field Definition

Field 1 – Total Number of Blocks

Description The number of individual fragments of time configuration table data, which when
reassembled, constitutes a complete time configuration table.

Field Length 4 Bytes

Domain Values 1…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the time configuration table data fragment
received.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Load Table Result

Description Notification of the success or the nature of the failure of the time configuration table
fragment loading process.

Field Length 4 Bytes

Domain Values LOAD_TIME_CONF_ACK_CONFIGURATION_OK = 00H,

LOAD_TIME_CONF_ACK_FRAGMENT_LOAD_OK = 10H,

LOAD_TIME_CONF_ACK_FAIL_UNKNOWN_FORMAT = 20H,

NATO UNCLASSIFIED 378

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

LOAD_TIME_CONF_ACK_FAIL_CHECKSUM_ERROR = 30H,

LOAD_TIME_CONF_ACK_FAIL_RESOURCE_ASSIGNMENT = 40H,

LOAD_TIME_CONF_ACK_UNKNOWN _ERROR = 50H.

12.7.2.2.3.2 Absolute Global Time (AGT) Transfer

The following services are required to enable a CFM to request the AGT from an external source.

12.7.2.2.3.2.1 Request_AGT

This message shall be transmitted when requesting an external time source to return the current
AGT. The format for this message shall be as shown in Figure 90, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000000H 16 0 x

Figure 90 - Request AGT Format

No additional information elements are required in this message.

12.7.2.2.3.2.2 Reply_AGT

This message shall be transmitted as a response to a request to return the current AGT. It shall
provide a status that indicates the ability to supply a valid time. If valid, it shall provide the time value
itself. The format for this message shall be as shown in Figure 91, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000001H 16 (See Table 56) x See Table 56

Figure 91 - Reply AGT Format

The MLI Message Payload field shall be encoded as follows:

Table 56 - Reply AGT Payload Field Definition

Field 1 – Reply AGT Status

Description Notification of the capability of the IA/AC to supply the AGT when its delivery is requested.

NATO UNCLASSIFIED 379

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values REPLY_AGT_VALID = 00H

REPLY_AGT_UNAVAILABLE = FFH

Field 2 – AGT Time in Seconds

Description The AGT value to the nearest second.

Field Length 4 Bytes

Domain Values 0…231-1

Field 3 – AGT Time in Nanoseconds

Description The AGT value to the nearest nanosecond.

Field Length 4 Bytes

Domain Values 0…109-1

12.7.2.2.3.3 Synchronisation Services

The following services are required to control the synchronisation of the time managed in a CFM from
a master time reference.

12.7.2.2.3.3.1 Ready_For_ALT_Synchro

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000010H 16 0 x

Figure 92 - Ready_For_ALT_Synchro Format

This message shall be transmitted as a notification to an RC or MRC from a CFM managing a

subordinate clock in the time management hierarchy of its readiness to be synchronised. In MLI
protocol management terms it is treated as a synchronisation request. The format for this message
shall be as shown in Figure 92.

No additional information elements are required in this message.

12.7.2.2.3.3.2 Start_ALT_Synchro

This message shall be transmitted by an MRC or RC to a subordinate CFM as a command to

synchronise its internally managed ALT to that of the RC or MRC. The transmission of this message
from the master clock initiates the periodic synchronisation process in the subordinate clock time
management and as such it is treated as a response to the request implied by the

NATO UNCLASSIFIED 380

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

“Ready_For_ALT_Synchro” message. The format for this message shall be as shown in Figure 93,
below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000011H 16 (See Table 57) x See Table 57

Figure 93 - Start_ALT_Synchro Format

The MLI Message Payload field shall be encoded as follows:

Table 57 - Start_ALT_Synchro Payload Field Definition

Field 1 – Master ALT Time in Seconds

Description Start time for the ALT synchronisation in seconds

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Master ALT Time in Nanoseconds

Description Start time for the ALT synchronisation in nanoseconds.

Field Length 4 Bytes

Domain Values 0…232-1

12.7.2.2.3.4 Absolute Local Time (ALT) Transfer

The following services are required to enable a CFM to request the ALT from a master CFM time
source.

12.7.2.2.3.4.1 Request_ALT

This message shall be transmitted when requesting an RC or MRC for the current Absolute Local
Time (ALT). The format for this message shall be as shown in Figure 94, below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000020H 16 0 x

Figure 94 - Request ALT Format

NATO UNCLASSIFIED 381

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

No additional information elements are required in this message.

12.7.2.2.3.4.2 Reply_ALT

This message is transmitted as a response to a request to a RC or MRC for the current Absolute
Local Time (ALT), providing both a status, indicating an ability to supply a valid time and, if valid, the
time value itself. The format for this message shall be as shown in Figure 95, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000021H 16 (See Table 58) x See Table 58

Figure 95 - Reply ALT Format

The MLI Message Payload field shall be encoded as follows.

Table 58 - Reply ALT Payload Field Definition

Field 1 – Reply ALT Status

Description Notification of the capability of the RC/MRC from which the ALT is requested to deliver
the ALT.

Field Length 4 Bytes

Domain Values REPLY_ALT_VALID = 00H,

REPLY_ALT_UNAVAILABLE = FFH.

Field 2 – ALT Time in Seconds

Description The ALT value to the nearest second.

Field Length 4 Bytes

Domain Values 0…231-1

Field 3 – ALT Time in Nanoseconds

Description The ALT value to the nearest nanosecond.

Field Length 4 Bytes

Domain Values 0…109-1

12.7.2.2.3.5 Combined AGT/ALT Transfer

The following services are required to enable a CFM to request the combined AGT/ALT time from a
master CFM time source.

NATO UNCLASSIFIED 382

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.3.5.1 Request_AGT_ALT

This message shall be transmitted when requesting an RC or MRC for the current combined
AGT/ALT time. The format for this message shall be as shown in Figure 96, below:

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000030H 16 0 x

Figure 96 - Request AGT ALT Format

No additional information elements are required in this message.

12.7.2.2.3.5.2 Reply_AGT_ALT

This message is transmitted as a response to a request to an RC or MRC for the current combined
AGT/ALT time. It provides both a status, indicating an ability to supply valid time values and, if those
values are valid, the time values themselves. The format for this message is shown in Figure 97,
below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

02000031H 16 (See Table 59) x See Table 59

Figure 97 - Reply AGT ALT Format

The MLI Message Payload field shall be encoded as follows.

Table 59 - Reply AGT ALT Payload Field Definition

Field 1 – Reply Time Status

Description Notification of the capability of the RC or MRC to deliver the combined AGT/ALT time as
requested.

Field Length 4 Bytes

Domain Values REPLY_AGT_ALT_VALID = 00H,

REPLY_AGT_ALT_UNAVAILABLE = FFH.

Field 2 – AGT Time in Seconds

Description The AGT value to the nearest second.

NATO UNCLASSIFIED 383

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values 0…231-1

Field 3 – AGT Time in Nanoseconds

Description The AGT value to the nearest nanosecond.

Field Length 4 Bytes

Domain Values 0…109-1

Field 4 – ALT Time in Seconds

Description The ALT value to the nearest second.

Field Length 4 Bytes

Domain Values 0…231-1

Field 5 – ALT Time in Nanoseconds

Description The ALT value to the nearest nanosecond.

Field Length 4 Bytes

Domain Values 0…109-1

12.7.2.2.4 Network Management Services

This subsection covers all services associated with the management of Network.

12.7.2.2.4.1 Network Configuration Transfer

The following services are required to enable a CFM to download Configuration data to a remote
NSM.

12.7.2.2.4.1.1 Load_Network_Configuration

This message shall be transmitted when issuing a request to load Network Switch Configuration
specified in the message with a whole or fragment of a whole Configuration data image. The format
for this message shall be as shown in Figure 98 below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

03000000H 16 (See Table 60) x See Table 60

Figure 98 - Load Network Configuration Format

NATO UNCLASSIFIED 384

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The MLI Message Payload fields shall be encoded as follows:

Table 60 - Load Network Configuration Payload Field Definition

Field 1 – Network Switch ID

Description The unique Identifier used to reference the physical Network Switch within the NSM to
be configured. This Id is hard-coded within the NSM.

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Network ID

Description The unique and logical Identifier used to reference the Network within the
ASAAC System. This Id associates the physical Network Switch to the logical
Network.

Field Length 4 Bytes

Domain Values 0…232-1

Field 3 – Total Number of Blocks

Description The number of individual fragments of Configuration data, which when reassembled,
constitutes a complete Configuration image.

Field Length 4 Bytes

Domain Values 1…232-1

Field 4 – Block Number

Description The sequentially numbered identifier of the Configuration image data fragment.

Field Length 4 Bytes

Domain Values 1…232-1

Field 5 – Image Size

Description The size, in bytes, of the overall image data when reassembled.

Field Length 4 Bytes

Domain Values 0…232-1

Field 6 – Fragment Size

Description The size, in bytes, of the image data fragment contained in this message. A fragment
size is multiple of 4.

Field Length 4 Bytes

Domain Values 0…232-1

NATO UNCLASSIFIED 385

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field 7 – Fragment Checksum

Description 32-bits checksum value of all the bytes contained in the Fragment Image data field
(field 8 – see below).

Field Length 4 Bytes

Domain Values 0…232-1

Field 8 – Fragment Image Data

Description Data for the image fragment transferred in this message

Field Length Variable

Domain Values 0…232-1

Field 8 of the MLI message represents one or several Network configuration fields, detailed in Figure
99. The total size of field 8 shall be a multiple of 24 bytes.

NSM Switch Configuration data

Command

4 bytes 20 bytes

Figure 99 – NSM Switch Command Format

The NSM switch command field shall be encoded as shown in Table 61.

Table 61 - NSM Switch Command Field Encoding

NSM Switch Command

Description NSM Switch Commands

Field Length 4 Bytes

Domain Values NSM_SWITCH_RESET = 1,

NSM_SWITCH_ADD_CONNECTION = 2,
NSM_SWITCH_REMOVE_CONNECTION = 3,
NSM_SWITCH_EXECUTE_SUB_COMMAND = 4.

The configuration data for each Network Command is specific to the Network Technology but shall
conform at a generic level as shown in Figure 100.

NSM_SWITCH_ADD_CONNECTION
NSM_SWITCH_REMOVE_CONNECTION

Control Input Port & Address Output Port & Address

4 bytes 8 bytes 8 bytes

NATO UNCLASSIFIED 386

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 100 – NSM Connection Command Format

The control field defined in Figure 100 can be used for any switch specific control, which may effect
input output routing, such as address masking. Multicast connections can be configured, by several
configuration requests with the same Input Port/Address field.

The Switch Reset command, see Figure 101, can be used at any time to return the switch, to the
initial state of an NSM module switch.

NSM_SWITCH_RESET

Reset parameters

20 bytes

Figure 101 – NSM Reset Command Format

The Execute Sub command, see Figure 102, is intended to allow control of Sub-function on the
switch, such as the Network Physical Layer.

NSM_SWITCH_EXECUTE_SUB_COMMAND

Sub Command Command parameters

4 bytes 16 bytes

Figure 102 – NSM Execute Command Format

12.7.2.2.4.1.2 Load_Network_Configuration_Acknowledge

This message shall be transmitted as an acknowledgement of a request to load a whole or fragment

of a whole Configuration image. It contains a status element as notification of its ability to carry out the
command. The format for this message shall be as shown in Figure 103, below

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

03000001H 16 (See Table 62) x See Table 62

Figure 103 - Load Network Configuration Acknowledge Format

The MLI Message Payload field shall be encoded as follows:

Table 62 - Load Network Configuration Acknowledge Payload Field Encoding

Field 1 – Total Number of Blocks

Description The number of individual fragments of Configuration image data, which when
reassembled, constitutes a complete Configuration image.

NATO UNCLASSIFIED 387

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Field Length 4 Bytes

Domain Values 1…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the Configuration image data fragment received.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Load Network Configuration Result

Description Notification of the success or the nature of the failure of the Configuration image loading
process.

Field Length 4 Bytes

Domain Values LOAD_ NETCONF_ACK_CONFIGURATION_OK = 00H,

LOAD_ NETCONF_ACK_FRAGMENT_LOAD_OK = 10H,

LOAD_ NETCONF_ACK_FAIL_UNKNOWN_FORMAT = 20H,

LOAD_ NETCONF_ACK_FAIL_CHECKSUM_ERROR = 30H,

LOAD_ NETCONF_ACK_FAIL_RESOURCE_ASSIGNMENT = 40H,

LOAD_ NETCONF_ACK_UNKNOWN _ERROR = 50H.

12.7.2.2.4.2 Network Status Transfer

The following services are required to enable one CFM to interrogate a remote NSM for the status of
the network specified in the message.

12.7.2.2.4.2.1 Request_Network_Status

This message shall be transmitted when requesting a NSM to report the current operational status of
a network. The format for this message shall be as shown in Figure 104, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

03000010H 16 4 x

(See Table 63) See Table 63

Figure 104 - Load Network Configuration Format

NATO UNCLASSIFIED 388

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The MLI Message Payload fields shall be encoded as follows.

Table 63 - Load Network Configuration Payload Field Encoding

Field 1 – Network ID

Description The unique and logical Identifier used to reference the Network within the ASAAC
System, whose status is required.

Field Length 4 Bytes

Domain Values 0…232-1

12.7.2.2.4.2.2 Reply_Network_Status

This message shall be transmitted when responding to a request to a NSM to report the operational
status of a specified network.

The format for this message shall be as shown in Figure 105, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

03000011H 16 (See Table 64) x See Table 64

Figure 105 – Reply Network Status Format

The MLI Message Payload field shall be encoded as follows.

Table 64 - Reply Network Status Payload Field Encoding

Field 1 – Network ID

Description The unique identifier, used to reference the Network ID whose status is required.

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Consolidated Network Status

Description Current Network operational status.

Field Length 4 Bytes

OK = 00H all ports are OK

Domain
Values
FAILED = FFH at least one port has failed

Field 3 – Network Ports Number

NATO UNCLASSIFIED 389

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description The number of Ports within this Network

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Detailed Port Status

Description List of records, showing the current operational status of all Network Ports.

X Bytes (dependent upon Network resources/configuration). For each Network Switch, a

Field Length
record of 8 Bytes is assigned for this purpose.

Domain Values See below.

Record Field 1 (Field 4, Record N) - Port ID

The unique identifier, used to reference the port within the Network Switch, to that the
Description
status information in the second field of a given record refers.

Field Length 4 Bytes

Domain Values 0…232-1

Record Field 2 (Field 4, Record N) – Port Status

Description Current Port operational status.

Field Length 4 Bytes

OK = 00H,
Domain Values
FAILED = FFH.

12.7.2.2.5 Power Switches Management Services

This subsection covers all services associated with the management of Power Switches.

12.7.2.2.5.1 Power Switches Configuration Transfer

The following services are required to enable one CFM to download Configuration data to a remote
PCM.

12.7.2.2.5.1.1 Load_Power_Switches_Configuration

This message shall be transmitted when issuing a request to load Power Switches Configuration with
a whole or fragment of a whole Configuration data image. The format for this message shall be as
shown in Figure 106, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID See Table 65

NATO UNCLASSIFIED 390

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

4 Bytes 4 Bytes 4 Bytes 4 Bytes

04000000H 16 (See Table 65) x

Figure 106 - Load Power Switches Configuration Format

The MLI Message Payload fields shall be encoded as follows.

Table 65 - Load Power Switches Configuration Payload Field Encoding

Field 1 – Total Number of Blocks

Description The number of individual fragments of Configuration data, which when reassembled,
constitutes a complete Configuration image.

Field Length 4 Bytes

Domain Values 1…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the Configuration image data fragment.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Image Size

Description The size, in bytes, of the overall image data when reassembled.

Field Length 4 Bytes

Domain Values 0…232-1

Field 4 – Fragment Size

Description The size, in bytes, of the image data fragment contained in this message. A fragment size
is multiple of 4.

Field Length 4 Bytes

Domain Values 0…232-1

Field 5 – Fragment Checksum

Description 32-bits checksum value of all the bytes contained in the Fragment Image data field (field 6
– see below).

Field Length 4 Bytes

Domain Values 0…232-1

Field 6 – Fragment Image Data

NATO UNCLASSIFIED 391

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Data for the image fragment transferred in this message

Field Length Variable

Domain Values 0…232-1

Field 6 of the MLI message represents one or several Power Switches configuration fields, detailed in
Figure 107. The total size of field 6 shall be a multiple of 8 bytes.

PCM Switch Command Configuration data

4 bytes 4 bytes

Figure 107 – PCM Switch Command Format

The PCM switch command field shall be encoded as shown in Table 66.

Table 66 - PCM Switch Command Field Encoding

PCM Switch Command

Description PCM Switch Commands

Field Length 4 Bytes

Domain Values PCM_ALL_SWITCHES_RESET = 1,

PCM_SWITCH_ON = 2,
PCM_SWITCH_OFF = 3.

The configuration data for each PCM Switch Command are as shown in Figure 108 and Figure 109.

PCM Switch Command Configuration data

PCM_SWITCH_ON Power Switch ID

PCM_SWITCH_OFF

4 bytes 4 bytes

Figure 108 – Power Switch Command Format

PCM Switch Command Configuration data

PCM_ALL_SWITCHES_RESET 0

4 bytes 4 bytes

Figure 109 – Power Switch Reset Format

NATO UNCLASSIFIED 392

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.5.1.2 Load_Power_Switches_Configuration_Acknowledge

This message shall be transmitted as an acknowledgement of a request to load a whole or fragment

of a whole Configuration image. It contains a status element as notification of its ability to carry out the
command. The format for this message shall be as shown in Figure 110, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

04000001H 16 (See Table 67) x See Table 67

Figure 110 – Power Switch Configuration Acknowledge Format

The MLI Message Payload field shall be encoded as follows.

Table 67 - Power Switch Configuration Acknowledge Payload Field Encoding

Field 1 – Total Number of Blocks

Description The number of individual fragments of Configuration image data, which when
reassembled, constitutes a complete Configuration image.

Field Length 4 Bytes

Domain Values 1…232-1

Field 2 – Block Number

Description The sequentially numbered identifier of the Configuration image data fragment received.

Field Length 4 Bytes

Domain Values 1…232-1

Field 3 – Load Power Switches Configuration Result

Description Notification of the success or the nature of the failure of the Configuration image loading
process.

Field Length 4 Bytes

Domain Values LOAD_ POWER_ACK_CONFIGURATION_OK = 00H,

LOAD_ POWER_ACK_FRAGMENT_LOAD_OK = 10H,

LOAD_ POWER_ACK_FAIL_UNKNOWN_FORMAT = 20H,

LOAD_ POWER_ACK_FAIL_CHECKSUM_ERROR = 30H,

LOAD_ POWER_ACK_FAIL_RESOURCE_ASSIGNMENT = 40H,

LOAD_ POWER_ACK_UNKNOWN _ERROR = 50H.

NATO UNCLASSIFIED 393

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.2.2.5.2 Power Switches Status Transfer

The following services are required to enable one CFM to interrogate a remote PCM for the status of
the Power Switches.

12.7.2.2.5.2.1 Request_Power_Switches_Status

This message shall be transmitted when requesting a PCM to report the current operational status of
a network. The format for this message shall be as shown in Figure 111 below.

MLI Message Header

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

04000010H 16 0 x

Figure 111 – Request Power Switch Status Format

No additional information elements are required in this message.

12.7.2.2.5.2.2 Reply_Power_Switches_Status

This message shall be transmitted when responding to a request to a PCM to report the operational
status of its Power Switches.

The format for this message shall be as shown in Figure 112, below.

MLI Message
MLI Message Header Payload

MLI Service ID Header Length Data Length Transfer ID

4 Bytes 4 Bytes 4 Bytes 4 Bytes

04000011H 16 (See Table 68) x See Table 68

Figure 112 – Reply Power Switches Status Format

The MLI Message Payload field shall be encoded as follows.

Table 68 - Reply Power Switches Status Payload Field Encoding

Field 1 – Power Switches Ports Number

Description The number of Ports within this PCM

Field Length 4 Bytes

Domain Values 0…232-1

Field 2 – Detailed Port Status

NATO UNCLASSIFIED 394

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description List of records, showing the current operational status of all Power Switches Ports.

X Bytes (dependent upon Power Switches resources/configuration). For each Power

Field Length
Switches Switch, a record of 8 Bytes is assigned for this purpose.

Domain Values See below.

Record Field 1 (Field 2, Record N) - Power Switch ID

The unique identifier, used to reference the Power Switch within the PCM, to that the
Description
status information in the second field of a given record refers.

Field Length 4 Bytes

Domain Values 0…232-1

Record Field 2 (Field 2, Record N) – Power Switch Status

Description Current Power Switch operational status.

Field Length 4 Bytes

ON = 00H

Domain Values OFF = FFH

LIMBO = 80H

Record Field 3 (Field 2, Record N) – Power Switch Voltage

Description Current Power Switch voltage (units millivolts).

Field Length 4 Bytes

Domain Values -231 .. 231 - 1

Record Field 4 (Field 2, Record N) – Power Switch Current

Description Current Power Switch current (units: milliampere).

Field Length 4 Bytes

Domain Values -231 .. 231 - 1

12.7.3 Protocol
This section covers general and specific protocol requirements for individual MLI services. It outlines
the use of particular MLI services in relation to:

- CFM resource management,

- CFM download management,

- CFM time management.

NATO UNCLASSIFIED 395

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.3.1 General Protocol Features

The protocol used for the various MLI services outlined in this specification relies on a
REQUEST/RESPONSE transaction i.e. for every service request there is an associated response.
The behaviour of the MLI manager in any CFM shall conform to the requirements in the following
sections. These requirements are common for all services (those specific to a given service are dealt
with in section 12.7.3.2).

12.7.3.1.1 Service Request Management

All MLI services rely on a REQUEST/RESPONSE protocol to carry out data or control transactions.

The MLI management in the CFM initiating the request (see section 12.7.3.1.3) shall record the
transmission of any MLI service request message, uniquely identified by a Transfer ID value and start
a timer. If the response associated with the previously transmitted request is received with the same
Transfer ID value as the request and within the expiry time of the timer (above), the record of the
initial request shall be deleted, the associated response timer stopped and notification of the arrival of
the response sent to the original requesting entity.

If no response to the initiating request is received before the timer expires (see section 12.7.3.1.3),
the record of the original request shall be deleted and notification of the timer expiry event (an error
condition) delivered to the original requesting entity.

If a response to the initiating request is received but the Transfer ID value does not match that of the
initiating request message, it shall be treated as an unsolicited service response (see section
12.7.3.1.2) and handled accordingly.

12.7.3.1.2 Unsolicited Service Response Handling

If an MLI service response is received for which there exists no record of the corresponding service
request initiation (see section 12.7.3.1.1), the CFM receiving this message shall release all associated
resources (discard the message) and issue a notification of the error condition.

12.7.3.1.3 Response Timers

Response timers are used as a means of recovering from the condition, whereby a CFM requesting
an MLI service receives no associated service response. The time after which the CFM requesting the
service deems that no response has been received (the response timer expiry) shall be determined
by the anticipated ability of the CFM’s in the given system to respond to such a request.

12.7.3.2 Specific Service Protocol Requirements

This section deals with protocol requirements specific to the usage of the individual services listed
here. In this section the following terms are used to denote specific entities within the system:

- MASTER CFM. This represents an MMM in an initialisation cycle, an MRC/RC in a time

management operation or an IA/AC in a system level transaction,

- SUBORDINATE CFM. This represents a remote CFM slaved to the MMM in an initialisation cycle,
an RC/MC in a time management operation or a subsystem in a system level transaction,

- PE – Processing Element hosted by a CFM.

In each case where special requirements are detailed in relation to particular services, the behaviour
outlined indicates how the entity supporting the service is required to carry out the associated action.

NATO UNCLASSIFIED 396

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Whereas the basic MLI protocol is outlined in section 12.7.3.1, all special protocol requirements other
than transfer direction restrictions indicate a ‘higher’ layer of protocol, the support of which is implicit
in the contents of the MLI payload data.

12.7.3.2.1 CFM Resource Management Services

The basic protocol relating to these services dictates that REQUEST messages propagate from a
MASTER source to SUBORDINATE destination e.g. MMM (PU) to remote CFM (MSU) transactions.
Similarly, the basic protocol also dictates that RESPONSE messages propagate from a
SUBORDINATE source to MASTER destination e.g. remote CFM (MSU) to MMM (PU) transactions.
This is illustrated in the diagram in Figure 113, below.

Figure 113 - General CFM Resource Management Protocol

12.7.3.2.1.1 PBIT Information Transfer

12.7.3.2.1.1.1 Request_PBIT_Result

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

Note, during power-up a situation may arise where a “Reply_PBIT_Result” message cannot be
delivered in response to a “Request_PBIT_Result” message because the resources required to

NATO UNCLASSIFIED 397

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

perform this action are undergoing a PBIT cycle and are, therefore, unavailable. Hence, a lack of
response to this request does not imply that the CFM is inoperative. This aspect of the behaviour of a
CFM shall be taken into account in the system initialisation cycle.

12.7.3.2.1.1.2 Reply_PBIT_Result

This is a response type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.1.2 CFM Status Transfer

12.7.3.2.1.2.1 Request_CFM_Status

This a request type service and shall be used in MASTER CFM to SUBORDINATE CFM transactions
only.

12.7.3.2.1.2.2 Reply_CFM_Status

This is a response type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.1.3 CFM Information Transfer

12.7.3.2.1.3.1 Request_CFM_Info

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.1.3.2 Reply_CFM_Info

This is a response type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.1.4 IBIT Start Transfer

12.7.3.2.1.4.1 Request_IBIT_Start

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.1.4.2 Reply_IBIT_Start

This is a response type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

NATO UNCLASSIFIED 398

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.3.2.1.5 IBIT Result Transfer

12.7.3.2.1.5.1 Request_IBIT_Result

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.1.5.2 Reply_IBIT_Result

This is a response type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.1.6 CFM Communication Test

12.7.3.2.1.6.1 Test_Message

This is a request type service and shall be used in a transaction between any two CFM’s. It basically
follows the protocol scheme as outlined in section 12.7.3.2.1, except there are no directional or
hierarchical restrictions on the use of this service.

12.7.3.2.1.6.2 Test_Message_Acknowledge

This is a response type service and shall be used in a transaction between any two CFM’s. It basically
follows the protocol scheme as outlined in section 12.7.3.2.1, except there are no directional or
hierarchical restrictions on the use of this service (see also section 12.7.3.2.2.1.1). It shall be
transmitted as a RESPONSE message so as to acknowledge the original REQUEST message
(“Test_Message”).

12.7.3.2.2 Download Management Services

The basic protocol relating to these services dictates that REQUEST messages propagate from a
MASTER source to SUBORDINATE destination e.g. MMM (PU) to remote CFM (MSU or PE)
transactions. Similarly, the basic protocol also dictates that RESPONSE messages propagate from a
SUBORDINATE source to MASTER destination e.g. remote CFM (MSU or PE) to MMM (PU)
transactions. This is illustrated in the diagram in Figure 114, below. Note, in this example, REMOTE
refers to a remote download target, which could be an MSU or PE, subject to the system image
download method used. In the case of communication configuration transfers, REMOTE refers to a
MSU only.

NATO UNCLASSIFIED 399

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Figure 114 - General Download Management Protocol

12.7.3.2.2.1 Image Transfer

This section covers the protocol requirements for the support of the Image download service only.
The additional protocol required to manage the Image download process is not included in this
section, as this would constitute a requirement of the Image download management.

12.7.3.2.2.1.1 Load_Image

This is a request type service and shall be used in MASTER CFM to PE or MASTER CFM to MSU
transactions only, where the destination is taken to be the image transfer endpoint.

12.7.3.2.2.1.2 Load_Image_Acknowledge

This is a response type service and shall be used in PE to MASTER CFM or MSU to MASTER CFM
transactions only.

12.7.3.2.2.1.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

NATO UNCLASSIFIED 400

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- LOAD_IMAGE_ACK_IMAGE_LOAD_OK: no error, it shall be returned after a successful and

complete image download,

- LOAD_IMAGE_ACK_FRAGMENT_LOAD_OK: no error, it shall be returned after a successful

fragmented block download,

- LOAD_IMAGE_ACK_FAILURE_ALREADY_LOADED: the transfer is aborted and the status is

returned at upper level,

- LOAD_IMAGE_ACK_FAILURE_UNKNOWN_FORMAT: the transfer is aborted and the status is

returned at upper level,

- LOAD_IMAGE_ACK_FAILURE_CHECKSUM_ERROR: the block is resent one time, if the same

error is resent: the transfer is aborted and the status is returned at upper level,

- LOAD_IMAGE_ACK_FAILURE_INSUFFICIENT_RESOURCES: the transfer is aborted and the

status is returned at upper level,

- LOAD_IMAGE_ACK_UNKNOWN_ERROR: the transfer is aborted and the status is returned at

upper level.

12.7.3.2.2.2 Routing Table Transfer

This section covers the protocol requirements for the support of the Routing Table download service
only. The additional protocol required to manage the Routing Table download process is not included
in this section as this would constitute a requirement of the Routing Table download management.

The Routing Table shall be processed at the end of the transfer. That means if the Routing Table
must be fragmented: This shall be a two phases process

- A first Routing Table is sent with only information concerning the direct sender/receiver TC’s. This
first table shall not be fragmented,

- A second Routing Table Transfer shall be processed with fragmentation.

If the fragmentation is not needed, the Routing Table shall be sent in a unique block.

12.7.3.2.2.2.1 Load_Routing_Table

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.2.2.2 Load_Routing_Table_Acknowledge

This is a response type service and is used in a SUBORDINATE CFM to MASTER CFM transaction.

12.7.3.2.2.2.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

- LOAD_RTG_TABLE_ACK_CONFIGURATION_OK: no error, it shall be returned after a

successful and complete image download and routing configuration,

NATO UNCLASSIFIED 401

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

- LOAD_RTG_TABLE_ACK_FRAGMENT_LOAD_OK: no error, it shall be returned after a

successful fragmented block download,

- LOAD_RTG_TABLE_ACK_FAIL_UNKNOWN_FORMAT: the status is returned at upper level,

- LOAD_RTG_TABLE_ACK_FAIL_CHECKSUM_ERROR: the block is resent one time, if the same

error is resent: the transfer is aborted and the status is returned at upper level,

- LOAD_RTG_TABLE_ACK_FAIL _RESOURCES_ASSIGNMENT: the status is returned at upper

level,

- LOAD_RTG_TABLE_ACK_UNKNOWN_ERROR: the transfer is aborted and the status is

returned at upper level.

12.7.3.2.3 Time management Services

Figure 115 - General Time Management Protocol

The General Time Management protocol is applicable to the Time Management services except the
Time Configuration that applies the General Download Management service. The basic protocol
relating to these services dictates that REQUEST messages propagate from a SUBORDINATE
source to MASTER destination e.g. remote CFM to MMM transactions. Similarly, the basic protocol
also dictates that RESPONSE messages propagate from a MASTER source to SUBORDINATE
destination e.g. MMM to remote CFM transactions. This section covers the protocol requirements for
the support of Time Management services only. The additional protocol required for use by the Time
Management process is not included in this section, as this would constitute a requirement. The basic
MLI protocol is illustrated in the diagram in Figure 115.

12.7.3.2.3.1 Time Configuration

This section covers the protocol requirements for the support of the Time Configuration download
service only.

NATO UNCLASSIFIED 402

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The General Download Management protocol shall be applicable to the Time Configuration download.
See 12.7.3.2.2.

The Time Configuration shall be processed at the end of the transfer. The Time Management shall be
processed when the whole table has been received and applied.

12.7.3.2.3.1.1 Load_Time_Configuration

This is a request type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.3.1.2 Load_ Time_Configuration _Acknowledge

This is a response type service and is used in a SUBORDINATE CFM to MASTER CFM transaction.

12.7.3.2.3.1.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

- LOAD_TIME_CONF_ACK_CONFIGURATION_OK: no error, it shall be returned after a

successful and complete image download and time configuration. The Time Management is
started,

- LOAD_TIME_CONF_ACK_FRAGMENT_LOAD_OK: no error, it shall be returned after a

successful fragmented block download,

- LOAD_TIME_CONF_ACK_FAIL_UNKNOWN_FORMAT: the status is returned at upper level.

The Time Management is not started,

- LOAD_TIME_CONF_ACK_FAIL_CHECKSUM_ERROR: the block is resent one time, if the same

error is resent: the transfer is aborted and the Time Management is not started,

- LOAD_TIME_CONF_ACK_FAIL _RESOURCES_ASSIGNMENT: the status is returned at upper

level. The Time Management is not started,

- LOAD_TIME_CONF_ACK_UNKNOWN_ERROR: the transfer is aborted. The Time Management

is not started.

12.7.3.2.3.2 AGT Transfer

12.7.3.2.3.2.1 Request_AGT

This is a request type service and shall be used in SUBORDINATE CFM to system external
(MASTER) transactions only.

12.7.3.2.3.2.2 Reply_AGT

This is a response type service and shall be used in system external (MASTER) to SUBORDINATE
CFM transactions only.

NATO UNCLASSIFIED 403

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.3.2.3.3 Synchronisation Services

12.7.3.2.3.3.1 Ready_For_ALT_Synchro

This is a request type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.3.3.2 Start_ALT_Synchro

This is a response type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.3.4 ALT Transfer

12.7.3.2.3.4.1 Request_ALT

This is a request type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.3.4.2 Reply_ALT

This is a response type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.3.5 Combined AGT/ALT Transfer

12.7.3.2.3.5.1 Request_AGT_ALT

This is a request type service and shall be used in SUBORDINATE CFM to MASTER CFM
transactions only.

12.7.3.2.3.5.2 Reply_AGT_ALT

This is a response type service and shall be used in MASTER CFM to SUBORDINATE CFM
transactions only.

12.7.3.2.4 Network Management Services

12.7.3.2.4.1 Network Configuration Transfer

This section covers the protocol requirements for the support of the Network Configuration download
service only.

The General Download Management protocol shall be applicable to the Network Configuration
download. See 12.7.3.2.2.

NATO UNCLASSIFIED 404

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

12.7.3.2.4.1.1 Load_Network_Configuration

This is a request type service and shall be used in MASTER CFM to SUBORDINATE NSM
transactions only.

12.7.3.2.4.1.2 Load_Network_Configuration _Acknowledge

This is a response type service and is used in a SUBORDINATE NSM to MASTER CFM transaction.

12.7.3.2.4.1.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

- LOAD_NETCONF_ACK_CONFIGURATION_OK: no error, it shall be returned after a successful

and complete configuration download and network routing configuration,

- LOAD_ NETCONF_ACK_FRAGMENT_LOAD_OK: no error, it shall be returned after a

successful fragmented block download,

- LOAD_ NETCONF_ACK_FAIL_UNKNOWN_FORMAT: the status is returned at upper level,

- LOAD_NETCONF_ACK_FAIL_CHECKSUM_ERROR: the block is resent one time, if the same

error is resent: the transfer is aborted and the status is returned at upper level,

- LOAD_NETCONF_ACK_FAIL_RESOURCES_ASSIGNMENT: the status is returned at upper

level,

- LOAD_NETCONF_ACK_UNKNOWN_ERROR: the transfer is aborted and the status is returned

at upper level.

12.7.3.2.4.2 Network Status Transfer

12.7.3.2.4.2.1 Request_Network_Status

This is a request type service and shall be used in MASTER CFM to SUBORDINATE NSM
transactions only.

12.7.3.2.4.2.2 Reply_Network_Status

This is a response type service and shall be used in SUBORDINATE NSM to MASTER CFM
transactions only.

12.7.3.2.5 Power Switches Management Services

12.7.3.2.5.1 Power Switches Configuration Transfer

This section covers the protocol requirements for the support of the Power Switches Configuration
download service only.

NATO UNCLASSIFIED 405

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

The General Download Management protocol shall be applicable to the Power Switches
Configuration download. See 12.7.3.2.2.

12.7.3.2.5.1.1 Load_Power_Switches_Configuration

This is a request type service and shall be used in MASTER CFM to SUBORDINATE PCM
transactions only.

12.7.3.2.5.1.2 Load_Power_Switches_Configuration _Acknowledge

This is a response type service and is used in a SUBORDINATE PCM to MASTER CFM transaction.

12.7.3.2.5.1.3 Error Handling

Following the receiving status of each fragmented blocks the corresponding action shall be:

- LOAD_POWER_ACK_CONFIGURATION_OK: no error, it shall be returned after a successful

and complete configuration download and Power Switches configuration,

- LOAD_ POWER_ACK_FRAGMENT_LOAD_OK: no error, it shall be returned after a successful

fragmented block download,

- LOAD_ POWER_ACK_FAIL_UNKNOWN_FORMAT: the status is returned at upper level,

- LOAD_POWER_ACK_FAIL_CHECKSUM_ERROR: the block is resent one time, if the same

error is resent: the transfer is aborted and the status is returned at upper level,

- LOAD_POWER_ACK_FAIL_RESOURCES_ASSIGNMENT: the status is returned at upper level,

- LOAD_POWER_ACK_UNKNOWN_ERROR: the transfer is aborted and the status is returned at

upper level.

12.7.3.2.5.2 Power Switches Status Transfer

12.7.3.2.5.2.1 Request_Power_Switches_Status

This is a request type service and shall be used in MASTER CFM to SUBORDINATE PCM
transactions only.

12.7.3.2.5.2.2 Reply_Power_Switches_Status

This is a response type service and shall be used in SUBORDINATE PCM to MASTER CFM
transactions only.

NATO UNCLASSIFIED 406

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

13 Data Type Definitions

13.4 IDL

IDL as defined by the CORBA standard (refer to [6]) is being used for all the service and data type
definitions of this standard. Together with the language mapping specification, which is also provided
by this standard, a unique definition of services and data types for a couple of languages (C, C++,
Ada, Java, SmallTalk) are provided with the IDL definitions.

This section just highlights a couple of points, which are required to understand the standard.

13.4.1 Basic Types

The CORBA standard defines a couple of basic integer types and it also defines the ranges for these
types.

Size and range of the integer types int and unsigned int types are not defined by the CORBA
standard. In order to avoid incompatibility, these types are not used within this standard.

The CORBA standard further defines long long and unsigned long long types. As it has turned out
that not all environments allow the usage of these types and a manual mapping may lead to
inconsistencies, also these types are not used by this standard.

Therefore, the following basic integer types are being used:

Table 69 - IDL Basic Integer Types

Type Name Range

short -215.. 215 - 1

long -231.. 231 - 1

unsigned short 0 .. 216 - 1

unsigned long 0 .. 232 - 1

The other basic types are being used as defined by the CORBA standard.

13.4.2 Name Spaces

Not every programming language provides a separation of name spaces. The CORBA standard
defines a unique mapping also for languages lacking an inherent definition of name spaces. The
prerequisite for this is that the separate name spaces definitions are provided by the IDL definition.

In order to provide the correct name scopes, the interface construct of IDL is being used. The
complete IDL definition of the interfaces therefore takes the following form:

// IDL:

// IDL definition of all types, including the data types

NATO UNCLASSIFIED 407

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

// that describe the message structure for logical interfaces

// ...

interface APOS {
// IDL definition of all APOS services
}

interface SMOS {
// IDL definition of all SMOS services
}

interface SMBP {
// IDL definition of all SMBP services
}

interface MOS {
// IDL definition of all MOS services

Figure 116 - Load Network Configuration Format

13.4.3 Limitations
In order to be applicable for common safety schemes like SPARK, the ‘in out’ parameter mode is not
used and where required it is replaced by two parameters, one for mode ‘in’ and one for mode ‘out’.

As ASAAC provides a standard for avionics an important requirement is that memory consumption
must be bounded, therefore all service parameters that are of parameter mode ‘out’, are bounded.
This means that any IDL sequence used is associated with a maximum size and any IDL array has a
static size.

13.5 Data Types

This section is defining all data types. The parameter descriptions in sections 11 and section 12 are
referencing these data type definitions by the type name. Therefore this section is normative for all
service definitions.

AcessInfo

Data Type Definition union AccessInfo switch ( AccessType ) {

case OLI_ACCESS :
OliChannel oli_channel;
case LOCAL_ACCESS :
unsigned long no_parameter;
};
Description The information regarding the type of access

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 408

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AccessRights

Data Type Definition enum AccessRights { R , W , D , RW , WD , RWD , F } ;

Description ‘R’: Read

‘W’: Write

‘D’: Delete

‘F’: deFault

Domain Values No special values are associated with this parameter.

AccessType

Data Type Definition enum AccessType { OLI_ACCESS , LOCAL_ACCESS } ;

Description The type of access for retrieving the executable file.

Domain Values No special values are associated with this parameter.

Action

Data Type Definition struct Action {

unsigned long action_number ;
long parameters[ MAX_NUMBER_OF_ACTION_PARAM ] ;
};
Description An action is specified by its number and its associated parameters

Domain Values No special values are associated with this parameter.

Address

Data Type Definition /* The definition of address type is implementation defined */

Description The definition of an Address is determined by the processor architecture. The only
use of the Address type is to reference message buffers and for error information.

Domain Values NIL: This constant is reserved for variable initialisation. It does not identify any object.

AlarmType

Data Type Definition enum AlarmType {

NO_ALARM ,
CYCLIC_ALARM ,
ONLY_ONCE_ALARM
} ;
Description Alarm type of timer.

NATO UNCLASSIFIED 409

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AlarmType

Domain Values CYCLIC_ALARM means the caller will be interrupted on a cyclic basis, defined in the
parameter time_tick_resolution, by the timer.

ONLY_ONCE_ALARM means that the timer will interrupt the caller only the first time
(after time_tick_resolution).

BitFinalResult

Data Type Definition enum BitFinalResult {

BIT_FINAL_RESULT_OK ,
BIT_FINAL_RESULT_FAIL
} ;
Description BIT final result.

Domain Values No special values are associated with this parameter.

BitResult

Data Type Definition struct BitResult {

BitType bit_type;
BitResultAll bit_result;
};
Description This allows providing BIT results from a sub-ordinate Fault Management Function to
a super-ordinate Fault Management Function directly connected to it.

Domain Values The content of each switch item is defined in the union BitResultAll.

BitResultAll

Data Type Definition union BitResultAll switch ( BitType ) {

case IBIT:
IbitResult ibit_result;
case CBIT:
CbitResult cbit_result;
case PBIT:
PbitResult pbit_result;
};
Description This allows providing BIT results from a sub-ordinate Fault Management Function to
a super-ordinate Fault Management Function directly connected to it.

Domain Values The content of each switch item is defined by the SMOS Bit definitions.

BitReturnStatus

Data Type Definition enum BitReturnStatus {

BIT_CALL_OK ,
BIT_CALL_FAILED
} ;

NATO UNCLASSIFIED 410

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

BitReturnStatus

Description Success of BIT MOS call.

Domain Values No special values are associated with this parameter.

BitTestStatus

Data Type Definition enum BitTestStatus {

BIT_PASSED ,
BIT_ONGOING ,
BIT_FAILED
} ;
Description This specifies the status of the Bit call.

BIT_PASSED signifies that the test has completed and passed within the last
StartCBIT invocation.

BIT_ONGOING – the specified test is PARTITIONED and has not completed within
the last StartCBIT invocation.

BIT_FAILED – the specified test has failed within the last StartCBIT invocation

Domain Values No special values are associated with this parameter.

BitType

Data Type Definition enum BitType { IBIT , CBIT , PBIT } ;

Description This allows defining the BIT type.

Domain Values No special values are associated with this parameter.

Bool

Data Type Definition enum Bool { BOOL_FALSE , BOOL_TRUE } ;

Description Boolean type

Domain Values No special values are associated with this parameter.

BreachType

Data Type Definition enum BreachType {

Non_Authorized_Service ,
Multi_Level_Security_Error ,
Unauthorized_Comms
};
Description Identifies possible security breach types, for use with getAuditData

NATO UNCLASSIFIED 411

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

BreachType

Domain Values No special values are associated with this parameter.

Category

Data Type Definition enum Category {

Level_1 ,
Level_2 ,
Level_3
} ;
Description

Domain Values No special values are associated with this parameter.

CbitDetailedResult

Data Type Definition struct CbitDetailedResult {

unsigned long no_bytes ;
char component_bit_result[MAX_CHAR_IN_CBIT_DETAILED_RESULT];
} ;
Description Detailed result of the CBIT

Domain Values No special values are associated with this parameter.

CbitModeType

Data Type Definition enum CbitModeType { PARTITIONED , COMPLETE } ;

Description This allows the caller to specify the method to use to run a test - either to completion
or in a series of defined sections called partitions.

Domain Values No special values are associated with this parameter.

CbitResult

Data Type Definition struct CbitResult {

BitFinalResult cbit_final_result ;
CbitDetailedResult cbit_detailed_result ;
} ;
Description CBIT result.

Domain Values No special values are associated with this parameter.

CfmDescription

Data Type Definition struct CfmDescription {

PublicId cfm_id ;

NATO UNCLASSIFIED 412

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

CfmDescription

CfmType cfm_type ;
// time_out for processing this cfm for this download
TimeInterval time_out ;
DownloadChannelType download_channel_type ;
DownloadChannel download_channel ;
DownloadType download_type ;
DownloadDescription download_description ;
} ;
Description Properties of the CFM.

Domain Values No special values are associated with this parameter.

CfmInfo

Data Type Definition struct CfmInfo {

octet id [ 4 ] ;
octet manufacturer_id [ 32 ] ;
octet part_no [ 256 ] ;
octet hw_version [ 256 ] ;
octet serial_no [ 256 ] ;
octet production_batch_date [ 32 ] ;
octet cfm_type [ 32 ] ;
octet msl_version[ 32 ] ;
octet standard_mpi_version_compliance [ 8 ] ;
octet standard_mos_version_compliance [ 8 ] ;
octet standard_mli_version_compliance [ 8 ] ;
unsigned long num_network ;
unsigned long num_pe ;
CfmResources cfm_resources ;
} ;
Description Unique CFM identification.

Domain Values No special values are associated with this parameter.

CfmInfoReturnStatus

Data Type Definition enum CfmParameterReturnStatus {

CFM_INFO_CALL_OK ,
CFM_INFO_CALL_FAILED
} ;
Description Success of a MOS CFM parameter service call

Domain Values No special values are associated with this parameter.

CfmMliChannel

Data Type Definition struct CfmMliChannel {

PublicId cfm_id ;
CfmType cfm_type ;
// These TC Ids are the end-point for reaching the MSL

NATO UNCLASSIFIED 413

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

CfmMliChannel

PublicId tc_sending ;
PublicId tc_receiving ;
// time_out for processing this cfm
TimeInterval time_out ;
} ;
Description Information on the MLI channel of a CFM Component.

Domain Values No special values are associated with this parameter.

CfmPartNo

Data Type Definition string

Description CFM part number.

Domain Values ASCII ISO Latin characters, except NULL.

CfmResources

Data Type Definition struct CfmResources {

PeResources pe[ 8 ] ;
unsigned long global_memory ;
TimerResources timer[ 8 ] ;
octet network_interfaces[ NETWORK_MAX_NO ] ;
} ;
Description CFM resources

Domain Values No special values are associated with this parameter.

CfmSerialNo

Data Type Definition string

Description CFM serial number.

Domain Values ASCII ISO Latin characters, except NULL.

CfmStat

Data Type Definition union CfmStat switch( CfmType ) {

case DPM :
case SPM :
case GPM :
case PCM :
case MMM :
CfmStatusPeGeneric pe_status ;
case NSM :
unsigned long no_parameter ;

NATO UNCLASSIFIED 414

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

} ;
Description Description of the CFM Status depending of the type of the CFM

Domain Values No special values are associated with this parameter.

CfmStatus

Data Type Definition struct CfmStatus {

CfmStatusGeneric status_generic ;
CfmType cfm_type;
CfmStat cfm_status ;
} ;
Description Description of the CFM Status that mirrors the MLI message

Domain Values No special values are associated with this parameter.

CfmStatusGeneric

Data Type Definition struct CfmStatusGeneric {

OpeStatus cfm_consolidated_status ;

OpeStatus pbit_status ;
OpeStatus cbit_status ;
OpeStatus ibit_status ;
OpeStatus rtg_download_status ;
OpeStatus msl_download_status ;
} ;
Description Description of the Status of CFM that conforms to the Generic CFM Model

Domain Values No special values are associated with this parameter.

CfmStatusPeGeneric

Data Type Definition struct CfmStatusPeGeneric {

unsigned long number_of_pe ;
PeStatus pe_status[ MAX_NUMBER_OF_PE ] ;
} ;
Description Description of the Status of all PE belonging to a CFM.

Domain Values No special values are associated with this parameter.

CfmStatusReturnStatus

Data Type Definition enum CfmStatusReturnStatus {

CFM_STATUS_CALL_OK ,
CFM_STATUS_CALL_FAILED
} ;
Description Success of a CFM status service call

NATO UNCLASSIFIED 415

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

CfmStatusReturnStatus

Domain Values No special values are associated with this parameter.

CfmType

Data Type Definition enum CfmType { PCM , NSM , MMM , DPM , SPM , GPM };

Description Values defined internally by the Blueprints for identifying the CFM type.

Domain Values No special values are associated with this parameter.

CfmVersion

Data Type Definition string

Description CFM version

Domain Values ASCII ISO Latin characters, except NULL.

CharacterSequence

Data Type Definition struct CharacterSequence {

unsigned long size ;
char data[ OS_MAX_STRING_SIZE ] ;
} ;
Description A bounded string has a maximum size (OS_MAX_STRING_SIZE ) that is determined
by the implementation of the operating system. It has an actual size, which
determines the actual length of an alphanumeric string, which is associated with the
bounded string type. The size is defined as the number of characters of the character
sequence excluding any termination (e.g. the NUL character) of the sequence.

Domain Values OS_MAX_STRING_SIZE >= 256

The maximum size of a string is determined by the OS implementation and it is driven

by efficiency and compatibility requirements. For compatibility therefore a minimum
for the size of 256 shall be guaranteed for any implementation.

NULL_CHARACTER_SEQUENCE
NULL_CHARACTER_SEQUENCE.size = 0 ;

This constant provides an empty character sequence for the Purpose of variable
initialisation.

ClassificationLevel

Data Type Definition enum ClassificationLevel {

Unclassified , Confidential , Secret , Top_Secret
} ;
Description Security classification.

NATO UNCLASSIFIED 416

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ClassificationLevel

Domain Values No special values are associated with this parameter.

ClockInfo

Data Type Definition struct ClockInfo {

ClockMode clock_mode ;

PublicId clock_id ; /* clock identifier */

PublicId tc_id_from_parent ;/*Cfm parent identifier */
PublicId tc_id_to_parent ; /*Cfm parent identifier */

TimeInterval sync_wave_period ;
unsigned long max_of_missed_alt ;
TimeInterval range_for_alt ;
TimeInterval alt_res_bound ;
TimeInterval max_alt_diff ;
TimeInterval timeout ;
} ;
Description ClockInfo describes the properties of a module local clock.

Domain Values No special values are associated with this parameter.

ClockMode

Data Type Definition enum ClockMode {

MASTER_REFERENCE_CLOCK , REFERENCE_CLOCK , MODULE_CLOCK
} ;
Description This type defines the different clock modes, which exist in the system.

Domain Values No special values are associated with this parameter.

ConfigTableDescription

Data Type Definition struct ConfigTableDescription {

// size in bytes of table
unsigned long table_size ;
CharacterSequence table_name ;
// size in bytes for fragmenting this image
unsigned long fragment_size ;
// How many times the fragment is resent after it has failed
unsigned long number_occurences ;
} ;
Description Properties of a configuration table downloading

Domain Values No special values are associated with this parameter.

DeleteOption

NATO UNCLASSIFIED 417

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DeleteOption

Data Type Definition enum DeleteOption { NORMAL , IMMEDIATELY } ;

Description NORMAL: Only deletes when all open accesses have been closed.

IMMEDIATELY: Users of the file effected lose all accesses and resources
(deleteFile)

Domain Values No special values are associated with this parameter.

DownloadChannel

Data Type Definition union DownloadChannel switch( DownloadChannelType ) {

case OLI_THEN_MLI :
OliMliChannel oli_mli_channel ;
case MLI :
MliChannel mli_channel ;
} ;
Description Properties of the download channel

Domain Values No special values are associated with this parameter.

DownloadChannelType

Data Type Definition enum DownloadChannelType { OLI_THEN_MLI , MLI } ;

Description Values defined internally by the Blueprint database System for identifying the type of
channel, which is used to download.

Domain Values No special values are associated with this parameter.

DownloadDescription

Data Type Definition union DownloadDescription switch( DownloadType ) {

case RTGTABLE_DOWNLOAD :
case POWER_DOWNLOAD :
case TIME_DOWNLOAD :
ConfigTableDescription config_table_description ;
case NETWORK_DOWNLOAD :
NetworkConfigDescription network_config_description ;
case IMAGE_DOWNLOAD :
ImageDescription image_description ;
} ;
Description Properties of the download

Domain Values No special values are associated with this parameter.

DownloadType

NATO UNCLASSIFIED 418

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

DownloadType

Data Type Definition enum DownloadType {

RTGTABLE_DOWNLOAD , NETWORK_DOWNLOAD , IMAGE_DOWNLOAD ,
POWER_DOWNLOAD , TIME_DOWNLOAD
} ;
Description Values defined internally by the Blueprints for identifying the download type.

Domain Values No special values are associated with this parameter.

ErrorCode

Data Type Definition typedef unsigned long ErrorCode ;

Description The error code provides a detailed identification of an error. This information is used
for debugging and as fault localisation data. In the first case it is implementation
dependent, in the second case system (function) dependent data. Therefore, a
standardisation of the error code values it not required. Only the domain values
define a rough localisation between architectural components.

Domain Values No special values are associated with this parameter.

ErrorInfo

Data Type Definition struct ErrorInfo {

ErrorCode error_code ;
ErrorType error_type ;
PublicId cfm_id ;
PublicId pe_id ;
PublicId process_id ;
PublicId thread_id ;
PublicId tc_id ;
PublicId vc_id ;
NetworkDescriptor network ;
Address location ;
Time absolute_global_time ;
Time absolute_local_time ;
Time relative_local_time ;
CharacterSequence error_message ;
} ;
Description Error information provides complete context and localisation information for an error
that has occurred.

Domain Values n/a

ErrorType

Data Type Definition enum ErrorType {

APPLICATION_ERROR ,
APOS_CLIENT_ERROR ,
RESOURCE_ERROR ,
OS_ERROR ,

NATO UNCLASSIFIED 419

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ErrorType

SMOS_ERROR ,
SMBP_ERROR ,
PROCESSOR_ERROR ,
HW_RESOURCE_ERROR ,
HW_FAILURE ,
FATAL_ERROR
} ;
Description The error type provides the classification of an error.

Domain Values APPLICATION_ERROR - Error explicitly raised by application process.

APOS_CLIENT_ERROR - Error due to erroneous usage of APOS service.
RESOURCE_ERROR - Lack of resources.
OS_ERROR - OS internal error.
SMOS_ERROR - Error occurred when using a SMOS service.
SMBP_ERROR - Error that occurred when using a SMBP service.
PROCESSOR_ERROR - A processor exception has occurred.
HW_RESOURCE_ERROR - Error occurred due to a lack of hardware resources.
HW_FAILURE - A hardware failure, which has been recognised by built-in test.
FATAL_ERROR - No recovery possible.

EventStatus

Data Type Definition enum EventStatus {

EVENT_STATUS_SET , EVENT_STATUS_RESET
} ;
Description An event has two states; it is either set or reset.

In the case an event is set, any thread waiting for the event is transferred into thread
ready status.

If an event is reset any thread waiting for the event is kept in thread status waiting
until the event is set.

Domain Values Inherent to type definition

EventType

Data Type Definition enum EventType {

COMMS_EV_ERROR , //general network
COMMS_EV_INFO , //network info return
COMMS_EV_CONFIGURED_OK , //network configured
COMMS_EV_BUFFER_SEND , //send buffer free
COMMS_EV_BUFFER_RECEIVED , //new buffer received
COMMS_TEST_RETURN , //Link test complete
COMMS_TEST_TIMEOUT , //Link test failed
TIMER_ALARM , //Time-out reached
CBIT_ERROR_DETECT , //Hardware error
MMM_SD_EVENT , //MMM. Disk DMA complete
DEV0_EVENT0 , // GPM. Graphics frame complete
KBD_PRESS // Debug extension
} ;

NATO UNCLASSIFIED 420

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description Event raised and to be handled by a callback handler.

Domain Values No special values are associated with this parameter., implementation dependent.

FaultReport

Data Type Definition struct FaultReport {

ErrorType error_type ;
ErrorCode error_code ;
PublicId system_id ;
PublicId ia_id ;
PublicId cfm_id ;
PublicId re_id ;
PublicId smm_id ;
PublicId config_id ;
PublicId pe_id ;
PublicId proc_id ;
PublicId thread_id ;
PublicId tc_id ;
PublicId vc_id ;
NetworkDescriptor network ;
unsigned long ia_error_count ;
Address fault_address ;
Time local_time ;
Time global_time ;
CharacterSequence error_message ;
} ;
Description This is a collection of possible error information.

Domain Values The content of the Fault Report GLI message is dependent on the Fault Localisation
method being applied, which is a system / implementation depended information.

FederatedClockInfo

Data Type Definition struct FederatedClockInfo {

ClockMode clock_mode ;
PublicId clock_id ; /* clock identifier */
PublicId Tc_Id_To_Federated ; /* To Cfm federated */
PublicId Tc_Id_From_Federated ; /* From Cfm federated */
} ;
Description This structure provides the properties of a subordinate (slaved) clock.

Domain Values No special values are associated with this parameter.

FunctionId

Data Type Definition typedef PublicId FunctionId;

Description A FunctionId is a GSM function whose id value is known at GSM implementation.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 421

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

GliAliveParameter

Data Type Definition struct GliAliveParameter {

PublicId function_id ;
PublicId status_id ;
};
Description Definition of parameters of the GLI messages Are_You_Alive and I_Am_Alive

Domain Values No special values are associated with this parameter.

GliMessage

Data Type Definition struct GliMessage {

GliMessageId unique_message_id ;
GliMessageParameter message_parameter;
} ;
Description Definition of GLI messages that may be exchanged between GSM functions.

Domain Values No special values are associated with this parameter.

GliMessageId

Data Type Definition enum GliMessageId {

Load_Configuration , Configuration_Loaded ,
Stop_Configuration , Configuration_Stopped ,
Run_Configuration , Configuration_Running ,
Change_Configuration , Configuration_Changed ,
Request_New_Cfm , Cfm_Allocated ,
Deallocate_Cfm , Cfm_Deallocated ,
Fault_Report,
Request_BIT_Result , Report_BIT_Result ,
Are_You_Alive , I_Am_Alive ,
Request_SC , SC_Response ,
DH_Send_M , DH_Send_X ,
DH_Send_XimodM , DH_Send_XjmodM ,
Request_Key , Send_Key
} ;
Description Definition of the Alternatives of GLI Messages.

Domain Values The value domain is defined by the type definition.

GliMessageParameter

Data Type Definition union GliMessageParameter switch( GliMessageId ) {

case Load_Configuration :
PublicId config_to_be_loaded ;
case Configuration_Loaded :
PublicId config_loaded ;
case Stop_Configuration :
PublicId config_to_be_acquired ;
case Configuration_Stopped :

NATO UNCLASSIFIED 422

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

GliMessageParameter

PublicId config_acquired ;
case Run_Configuration :
PublicId config_to_be_run ;
case Configuration_Running :
PublicId config_run ;
case Change_Configuration :
PublicId configuration_event ;
case Configuration_Changed :
PublicId new_configuration ;
case Request_New_Cfm :
unsigned long no_parameter;
case Cfm_Allocated :
PublicId Allocated_Cfm_Id ;
case Deallocate_Cfm :
PublicId Deallocate_Cfm_Id ;
case Cfm_Deallocated :
PublicId Deallocated_Cfm_Id ;
case Fault_Report :
FaultReport the_fault ;
case Request_BIT_Result :
BitType type ;
case Report_BIT_Result :
BitResult result ;
case Are_You_Alive:
case I_Am_Alive:
GliAliveParameter alive_param;
case Request_SC :
PublicId request_sc_tls_id ;
case SC_Response :
Bool response ;
case DH_Send_M :
case DH_Send_X :
case DH_Send_XimodM :
case DH_Send_XjmodM :
unsigned long key ;
case Request_Key :
PublicId request_key_tls_id ;
case Send_Key :
unsigned long key_array[ 10 ];
} ;
Description Definition of parameter of GLI messages depending of the GliMessageId

Domain Values No special values are associated with this parameter.

GsmConfigData

Data Type Definition struct GsmConfigData {

// Implementation Dependent
} ;
Description This structure is dependent on the GSM implementation. Each table may be specific.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 423

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

IbitDetailedResult

Data Type Definition struct IbitDetailedResult {

unsigned long no_bytes ;
char
component_bit_result[ MAX_CHAR_IN_IBIT_DETAILED_RESULT ] ;
} ;
Description Detailed result of the IBIT

Domain Values No special values are associated with this parameter.

IbitResult

Data Type Definition struct IbitResult {

BitFinalResult ibit_final_result ;
IbitDetailedResult ibit_detailed_result ;
} ;
Description IBIT result.

Domain Values No special values are associated with this parameter.

IdentAposService

Data Type Definition enum IdentAposService {

APOS_sendMessageNonblocking ,
APOS_receiveMessageNonblocking ,
APOS_sendMessage ,
APOS_receiveMessage ,
APOS_lockBuffer ,
APOS_sendBuffer ,
APOS_receiveBuffer ,
APOS_unlockBuffer ,
APOS_waitOnMultiChannel ,
APOS_createSemaphore ,
APOS_deleteSemaphore ,
APOS_waitForSemaphore ,
APOS_postSemaphore ,
APOS_getSemaphoreStatus ,
APOS_getSemaphoreId ,
APOS_createEvent ,
APOS_deleteEvent ,
APOS_setEvent ,
APOS_resetEvent ,
APOS_waitForEvent ,
APOS_getEventStatus ,
APOS_getEventId ,
APOS_getAbsoluteGlobalTime ,
APOS_getAbsoluteLocalTime ,
APOS_getRelativeLocalTime ,
APOS_sleep ,
APOS_sleepUntil ,
APOS_getMyThreadId ,
APOS_terminateSelf ,

NATO UNCLASSIFIED 424

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

IdentAposService

APOS_terminateErrorHandler ,
APOS_suspendSelf ,
APOS_startThread ,
APOS_stopThread ,
APOS_lockThreadPreemption ,
APOS_unlockThreadPreemption ,
APOS_getThreadStatus ,
APOS_createFile ,
APOS_deleteFile ,
APOS_openFile ,
APOS_closeFile ,
APOS_getFileAttributes ,
APOS_readFile ,
APOS_writeFile ,
APOS_createDirectory ,
APOS_deleteDirectory ,
APOS_seekFile ,
APOS_lockFile ,
APOS_unlockFile ,
APOS_getFileBuffer ,
APOS_releaseFileBuffer ,
APOS_setPowerSwitch ,
APOS_resetPowerSwitches ,
APOS_getPowerSwitch ,
APOS_logMessage ,
APOS_raiseApplicationError ,
APOS_getErrorInformation,
number_of_APOS_services
} ;
Description All APOS services are enumerated in this type.

Domain Values No special values are associated with this parameter.

ImageDescription

Data Type Definition struct ImageDescription {

PublicId pe_id ;
// size in bytes of image
unsigned long image_size ;
CharacterSequence image_name ;
//specified in a field of bits the content of the image
unsigned long image_content ;
// size in bytes for fragmenting this image
unsigned long fragment_size ;
// How many times the fragment is resent after it has failed
unsigned long number_occurrences ;
// size in bytes of the project dependent load_instructions
unsigned long load_instruction_size ;
// project dependent information
LoadInstructions load_instructions ;
} ;
Description Properties of the image downloading

NATO UNCLASSIFIED 425

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ImageDescription

Domain Values No special values are associated with this parameter.

InputLocalParameters

Data Type Definition union InputLocalParameters switch( RemoteServiceId ) {

case NETWORK_STATUS :
PublicId network_id ;
case PBIT_RESULT :
case CFM_STATUS :
case CFM_INFO :
case POWER_STATUS :
case TEST_MESSAGE :
case IBIT_START :
case IBIT_RESULT :
unsigned long no_parameter ;
};
Description Description of input parameters associated to a remote service Id

Domain Values No special values are associated with this parameter.

InterfaceConfigurationData

Data Type Definition struct InterfaceConfigurationData {

unsigned long configuration_data_length ;
InterfaceDescription configuration_data ;
} ;
Description A unique value used to describe the configuration parameters of an interface used for
NII communication.

Domain Values No special values are associated with this parameter.

InterfaceDescription

Data Type Definition typedef octet InterfaceDescription [INTERFACE_CONFIG_MAX_LEN];

Description Describes the resource requirements of the Interface depending on the interface type.

Domain Values No special values are associated with this parameter.

InterfaceData

Data Type Definition struct InterfaceData {

PublicId if_id ;
NetworkDescriptor nw_id ;
// In a Multi-Processor environment: the
// processor that configures this interface
PublicId cpu_id ;
InterfaceType conf_data_type ;

NATO UNCLASSIFIED 426

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

InterfaceData

// contains the length of the subsequent

// variant record InterfaceConfigurationData
unsigned long conf_data_size ;
InterfaceConfigurationData conf_data ;
};
Description Describes the properties of an Interface used for communicating via TC.

Domain Values No special values are associated with this parameter.

InterfaceType

Data Type Definition enum InterfaceType {

// Project dependent type defining different Interfaces
// for the current implementation
} ;
Description Describes the different Interfaces of the current implementation

Domain Values No special values are associated with this parameter.

IOoperation

Data Type Definition enum IOoperation {

IO_no_op , IO_read , IO_write , IO_seek , IO_test
} ;
Description Specifies the type of operation to be performed on the memory device

Domain Values No special values are associated with this parameter.

LoadFileResult

Data Type Definition enum LoadFileResult {

RET_LOAD_ACK_LOAD_OK ,
RET_LOAD_ACK_FAILURE_ALREADY_LOADED ,
RET_LOAD_ACK_FAILURE_UNKNOWN_FORMAT ,
RET_LOAD_ACK_FAILURE_CHECKSUM_ERROR ,
RET_LOAD_ACK_FAILURE_INSUFFICIENT_RESOURCES ,
RET_LOAD_ACK_UNKNOWN_ERROR ,
RET_LOAD_INVALID_TC ,
RET_LOAD_INVALID_SERVICE ,
RET_LOAD_TIME_OUT
};
Description Notification of the success or the nature of the failure of the image loading process.

Domain Values Inherent to type definition

LoadInstructions

NATO UNCLASSIFIED 427

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

LoadInstructions

Data Type Definition struct LoadInstructions {

/*Project dependent information */
} ;
Description Description of loading instructions

Domain Values No special values are associated with this parameter.

LockStatus

Data Type Definition enum LockStatus { LOCKED , UNLOCKED } ;

Description LOCKED: The file is locked.

UNLOCKED: The file is not locked.

Domain Values No special values are associated with this parameter.

Log

Data Type Definition typedef sequence < string > Log ;

Description Log contents.

Domain Values ASCII ISO Latin characters, except NULL.

The maximum length of a fault log is 255 characters plus a NULL termination
character.

LogMessageType

Data Type Definition enum LogMessageType {

LOG_MESSAGE_TYPE_ERROR ,
LOG_MESSAGE_TYPE_APPLICATION ,
LOG_MESSAGE_TYPE_GSM ,
LOG_MESSAGE_TYPE_MAINTENANCE
} ;
Description The message logging discriminates between different types of logging messages.

Domain Values LOG_MESSAGE_TYPE_ERROR - An error log entry.

LOG_MESSAGE_TYPE_APPLICATION - An application entry to the module log.

LOG_MESSAGE_TYPE_GSM - An entry to the module log made by the Generic

System Management.

LOG_MESSAGE_TYPE_MAINTENANCE - An entry to the module log that is

relevant for maintenance purpose.

NATO UNCLASSIFIED 428

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

LogReturnStatus

Data Type Definition unsigned long

Description

Domain Values MOS_LOG_CALL_OK

MOS_LOG_CALL_FAILED
MOS_LOG_READ_INDEX_OUT_OF_RANGE

MemoryUsage

Data Type Definition enum MemoryUsage { READ_ONLY , READ_WRITE } ;

Description Determines the type of memory access that a virtual memory area is allowed to have
to an attached region.

Domain Values Inherent to type definition

MliChannel

Data Type Definition struct MliChannel {

PublicId tc_sending ;
PublicId tc_receiving ;
} ;
Description Properties of channel using MLI

Domain Values No special values are associated with this parameter.

MSLStatus

Data Type Definition enum MSLStatus {

MSL_OK ,
MSL_FAILED ,
MSL_INVALID_PARAMETER ,
MSL_FAILED_TO_CREATE_REGION ,
MSL_FAILED_TO_DELETE_REGION ,
MSL_FAILED_TO_ATTACH_REGION ,
MSL_FAILED_TO_DETACH_REGION ,
MSL_FAILED_TO_CREATE_VM ,
MSL_FAILED_TO_DELETE_VM ,
MSL_INVALID_LINEAR_ADDRESS ,
MSL_INVALID_REGION_ID ,
MSL_INVALID_VM_ID ,
MSL_FAILED_TO_ADD_SEP ,
MSL_FAILED_TO_CREATE_CONTEXT ,
MSL_FAILED_TO_DELETE_CONTEXT ,
MSL_FAILED_TO_SWITCH_CONTEXT ,
MSL_FAILED_TO_REGISTER_CALLBACK ,
MSL_FAILED_TO_DELETE_CALLBACK ,
MSL_INVALID_EVENT_ID ,
MSL_CALLBACK_INVALID_PARAMETER ,
MSL_CALLBACK_FAILED ,

NATO UNCLASSIFIED 429

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

MSL_FAULT_LOG_SUCCESS ,
MSL_TIMER_NO_ALARM ,
MSL_TIMER_INVALID_ALARM ,
MSL_TIMER_INVALID_ID ,
MSL_IO_FAILED ,
MSL_IO_BUSY ,
MSL_INVALID_CALL
} ;
Description The service returns the status of the File Service request

Domain Values Inherent to type definition

NetworkConfigDescription

Data Type Definition struct NetworkConfigDescription {

// 1..232 = Network Configuration
PublicId network_id ;
// size in bytes of table
unsigned long table_size ;
CharacterSequence table_name ;
// size in bytes for fragmenting this image
unsigned long fragment_size ;
// How many times the fragment is resent after it has failed
unsigned long number_occurences ;
} ;
Description Properties of the Network configuration downloading

Domain Values No special values are associated with this parameter.

NetworkDescriptor

Data Type Definition struct NetworkDescriptor {

PublicId network ;
PublicId port ;
};
Description An identifier within the CFM for a defined interface in a network. The identifier is
composed of:

network, which is a unique value within the system used to identify a particular
network

port, which is a unique value within the CFM used to identify a particular interface
connected to a network.

Domain Values No special values are associated with this parameter.

NetworkInterface

Data Type Definition struct NetworkInterface {

NetworkDescriptor network_type ;
unsigned long number_links ;
} ;

NATO UNCLASSIFIED 430

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NetworkInterface

Description Routing Unit description

Domain Values Number of network links: 0..64

NetworkPortFinalStatus

Data Type Definition enum NetworkPortFinalStatus { HEALTHY , FAULTY } ;

Description A unique value used to describe the status of a network port.

Domain Values No special values are associated with this parameter.

NetworkPortState

Data Type Definition struct NetworkPortState {

PublicId port_id ;
NetworkPortFinalStatus status ;
} ;
Description Description of the Status of a port of a Network

Domain Values No special values are associated with this parameter.

NetworkPortStatus

Data Type Definition struct NetworkPortStatus {

NetworkPortFinalStatus final_status ;
unsigned long status_data_length ;
octet detailed_status_data
[ NW_PORT_STATUS_MAX_LEN ] ;
} ;
Description Operational status of a port of a Network

Domain Values No special values are associated with this parameter.

NiiReturnStatus

Data Type Definition enum NiiReturnStatus {

MOS_NII_CALL_COMPLETE , //Call successful
MOS_NII_CALL_OK , //Call accepted
MOS_NII_CALL_FAILED , //Call failed
MOS_NII_INVALID_INTERFACE , //Interface undefined
MOS_NII_INVALID_NETWORK , //Network undefined
MOS_NII_INVALID_TC , //TC undefined
MOS_NII_INVALID_CONFIG , //Bad config data
MOS_NII_INVALID_PARAMETER , //Bad config data
MOS_NII_ALREADY_CONFIGURED , //No config change
MOS_NII_TC_NOT_CONFIGURED , //TC not available
MOS_NII_OPEN_TCS , //network TC are still there

NATO UNCLASSIFIED 431

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NiiReturnStatus

MOS_NII_INVALID_MESSAGE_SIZE , //Bigger than buffer

MOS_NII_BUFFER_NOT_READY , //Buffer in use
MOS_NII_BUFFER_EMPTY , //Not got all data
MOS_NII_STORAGE_FAULT , //Bad config data
MOS_NII_STATUS_OK , //Network OK
MOS_NII_STATUS_ERROR , //Network error
MOS_NII_STATUS_INIT //Net initialising
} ;
Description Success of a MOS communications service call. The concrete domain values are
dependent on the used service call.

Domain Values No special values are associated with this parameter.

NetworkStatus

Data Type Definition struct NetworkStatus {

PublicId network_id ;
NetworkPortStatus consolidated_status ;
unsigned long nb_of_ports ;
NetworkPortState port_status[ MAX_NUMBER_OF_PORTS ] ;
} ;
Description Description of the Status of a Network

Domain Values No special values are associated with this parameter.

Node

Data Type Definition typedef unsigned long Node ;

Description A Node is a handle to provide access to specific information from the RTBP. The
SMBP services implement the access to the RTBP as a tree.

Domain Values No special values are associated with this parameter.

NodeList

Data Type Definition struct NodeList {

unsigned long iterator ;
unsigned long actual_size ;
Node nodes[ MAX_NUMBER_OF_NODES ] ;
} ;
Description A node list contains all subsequent nodes relative to a provided node. To enable the
list to maintain the iterator by itself, an iterator index is also included in the data
structure.

The size parameter contains the actual number of Nodes

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 432

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

OctetSequence

Data Type Definition typedef octet OctetSequence[ OS_MAX_STRING_SIZE ] ;

Description A fixed size array of bytes.

Domain Values No special values are associated with this parameter.

OliChannel

Data Type Definition struct OliChannel {

PublicId vc_sending ;
PublicId vc_receiving ;
unsigned long fragment_size ;
// if the fragment size equal to the proramme file size,
// the transfer is performed once.
};
Description Properties of channel using OLI

Domain Values No special values are associated with this parameter.

OliMessageId

Data Type Definition enum OliMessageId {

RequestFileRead ,
ReplyFileRead ,
RequestMliDownload ,
ReplyMliDownload
} ;
Description Definition of the Alternatives of OLI Messages.

Domain Values No special values are associated with this parameter.

OliMessage

Data Type Definition struct OliMessage {

unsigned long transfer_id ;
OliMessageId unique_message_id ;
OliMessageParameter message_parameter ;
} ;
Description Definition of any OLI message that may be exchanged between OS.

Domain Values No special values are associated with this parameter.

OliMessageParameter

Data Type Definition union OliMessageParameter switch( OliMessageId ) {

case RequestFileRead:
RequestFileReadPayload request_read_file ;
case ReplyFileRead:

NATO UNCLASSIFIED 433

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

OliMessageParameter

ReplyFileReadPayload reply_read_file ;
case RequestMliDownload:
RequestRemoteMliDownload request_mli_download ;
case ReplyMliDownload:
ReplyRemoteMliDownload reply_mli_download ;
} ;
Description Definition of parametrs of OLI message depending of OliMessageId.

Domain Values No special values are associated with this parameter.

OliMliChannel

Data Type Definition struct OliMliChannel {

// VC for the OLI Transfer to the MMM
PublicId vc_sending ;
PublicId vc_receiving ;
// TC for the MLI Transfer from the MMM
PublicId tc_sending ;
PublicId tc_receiving ;
} ;
Description Properties of channel using first OLI then MLI

Domain Values No special values are associated with this parameter.

OpeStatus

Data Type Definition enum OpeStatus {

OK , FAILED , NOT_AVAILABLE , IN_PROGRESS
} ;
Description Operational status mirroring the MLI information

Domain Values No special values are associated with this parameter.

OutputRemoteParameters

Data Type Definition union OutputRemoteParameters

switch( RemoteServiceId ) {
case PBIT_RESULT :
PbitResult powerup_bit_result ;
case CFM_STATUS :
CfmStatus module_status ;
case CFM_INFO :
CfmInfo module_info ;
case NETWORK_STATUS :
NetworkStatus net_status ;
case POWER_STATUS :
PowerSwitch power_switch_status ;
case TEST_MESSAGE :
case IBIT_START :
unsigned long no_parameter ;

NATO UNCLASSIFIED 434

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

OutputRemoteParameters

case IBIT_RESULT :
IbitResult interruptive_bit_result ;
};
Description Description of output parameters associated to a remote service Id

Domain Values No special values are associated with this parameter.

PbitDetailedResult

Data Type Definition struct PbitDetailedResult {

unsigned long no_bytes ;
char component_bit_result[MAX_CHAR_IN_PBIT_DETAILED_RESULT];
} ;
Description Detailed result of the PBIT

Domain Values No special values are associated with this parameter.

PbitResult

Data Type Definition struct PbitResult {

BitFinalResult pbit_final_result ;
PbitDetailedResult pbit_detailed_result ;
} ;
Description PBIT result.

Domain Values No special values are associated with this parameter.

PeIdReturnStatus

Data Type Definition enum PeIdReturnStatus {

PE_ID_CALL_OK ,
PE_ID_CALL_FAILED
} ;
Description Success of a PE ID service call

Domain Values No special values are associated with this parameter.

PeInfoReturnStatus

Data Type Definition enum PeInfoReturnStatus {

PE_INFO_CALL_OK ,
PE_INFO_CALL_FAILED
} ;
Description Success of a PE Info service call

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 435

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

PeResources

Data Type Definition struct PeResources {

PublicId pe_id ;
PeType type ;
unsigned long performance ;
unsigned long memory ;
};
Description Processing Element Resource Description

Domain Values memory: Processing Element memory in Mbytes.

performance: Processing Element performance in MOPS, MFLOPS

A.1.1.1. PeStatus

Data Type Definition struct PeStatus {

PublicId pe_id ;
OpeStatus pbit_status ;
OpeStatus cbit_status ;
OpeStatus ibit_status ;
OpeStatus rtg_download_status ;
OpeStatus msl_download_status ;
OpeStatus os_download_status ;
OpeStatus gsm_download_status ;
OpeStatus rtbp_download_status ;
} ;
Description Description of the PE Status

Domain Values No special values are associated with this parameter.

PeType

Data Type Definition typedef octet PeType[ 32 ] ;

Description Processing Element type

Domain Values No special values are associated with this parameter.

PoolType

Data Type Definition enum PoolType {

CODE_RAM , DATA_RAM , STACK_RAM , DEV_RAM , BUFFER ,
TFC , STREAM_BUFFER
} ;
Description Determines the pool from which memory can be obtained.

Domain Values Inherent to type definition

NATO UNCLASSIFIED 436

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

PowerSwitch

Data Type Definition struct PowerSwitch {

unsigned long number_switches ;
SwitchStatus switch_state[MAX_NUMBER_OF_POWER_SWITCHES] ;
} ;
Description Describes the status of all switches of a PCM

Domain Values No special values are associated with this parameter.

PowerSwitchReturnStatus

Data Type Definition enum PowerSwitchReturnStatus {

POWER_SWITCH_CALL_OK ,
POWER_SWITCH_CALL_FAILED
};
Description Success of BIT MOS call

Domain Values No special values are associated with this parameter.

ProcessDescription

Data Type Definition struct ProcessDescription {

PublicId global_pid ;
// fully specified (i.e. including path name) name of the
// programme file (note, this is the executable object
// in platform dependent binary format)
CharacterSequence programme_file_name ;
unsigned long programme_file_Size ;
AccessType access_type ;
AccessInfo access_info ;
// In a Multi-Processor environment: the
// processor in charge of executables downloading
PublicId cpu_id ;
ServiceAccessList apos_services ;
TimeInterval timeout ;
} ;
Description Structure describing a process.

Timeout specifies the maximum time create process may take to retrieve the process
code (via OLI) and complete the process creation.

Domain Values No special values are associated with this parameter.

PrivateId

Data Type Definition typedef unsigned long PrivateId ;

Description Any identifier that is used only at a single interface is a private identifier. Its particular
value is completely left to the discretion of the producer of the identifiers value being
responsible for controlling the objects the identifier is referring to.

NATO UNCLASSIFIED 437

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

PrivateId

Domain Values No special values are associated with this parameter.

PublicId

Data Type Definition typedef unsigned long PublicId ;

Description Any value that is referencing an object is an identifier. If that the value is used at
more than one interface, then this identifier is a public identifier. Its value can
reference a specific object from several components. For instance the identifier value
of a thread shows up in the application process at the APOS interface and the same
value shows up at the SMBP and SMOS interfaces in a GSM process configuring the
application process.

Domain Values 0 .. 232 – 1

PublicIdSet

Data Type Definition typedef PublicId PublicIdSet[ OS_MAX_PUBLIC_ID_SET_SIZE ] ;

Description The set consists of a bounded number of public identifiers. The maximum set size
OS_MAX_PUBLIC_ID_SET_SIZE is determined by the operating system
implementation. The set has an actual size that is the number of set elements. The
actual size is lower or equal to its maximum size.

Domain Values OS_MAX_PUBLIC_ID_SET_SIZE >= 256

The maximum size of a set of public identifiers is determined by the OS. For
compatibility a minimum of 256 shall be guaranteed for any implementation.

NULL_PUBLIC_ID_SET

This constant provides an empty set of public identifiers for the purpose of variable
initialisation.

QueuingDiscipline

Data Type Definition enum QueuingDiscipline {

QUEUING_DISCIPLINE_FIFO ,
QUEUING_DISCIPLINE_PRIORITY
} ;
Description The Queuing Discipline determines the queuing order of threads, which are waiting
for a semaphore.

In the case of QUEUING_DISCIPLINE_FIFO the threads are queued in the order the
service waitForSemaphore is called by the threads.

In the case of QUEUING_DISCIPLINE_PRIORITY the threads are queued in the

order of their scheduling priority.

Domain Values Inherent to type definition

NATO UNCLASSIFIED 438

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ReadFileResult

Data Type Definition enum ReadFileResult {

READ_FILE_ACK_OK ,
READ_FILE_ACK_FAILURE_NO_FILE ,
READ_FILE_ACK_FAILURE_NO_READ_ACCESS
} ;
Description Notification of the success or the nature of the failure of the File Reading process.

Domain Values Inherent to type definition

RegionID

Data Type Definition typedef unsigned long RegionID ;

Description Specifies the memory region for data storage.

Domain Values 0 ≤ RegionID ≤ 232-1

RemoteServiceId

Data Type Definition enum RemoteServiceId {

PBIT_RESULT , CFM_STATUS , CFM_INFO , NETWORK_STATUS ,
POWER_STATUS , TEST_MESSAGE , IBIT_START , IBIT_RESULT
} ;
Description Description of the remote service Id

Domain Values No special values are associated with this parameter.

ReturnStatus

Data Type Definition enum ReturnStatus { SUCCESS , ERROR } ;

Description The return value provides information on the successful completion of a APOS thread
service.

Domain Values SUCCESS - service completes successfully

ERROR - service failure due to an error

ResourceReturnStatus

Data Type Definition enum ResourceReturnStatus {

RS_SUCCESS, RS_ERROR , RS_RESOURCE
} ;
Description The resource return value provides information on the successful completion of a
APOS thread service and whether an resource error occurs for a resource under the
control of the function, which is implemented by the calling component.

NATO UNCLASSIFIED 439

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ResourceReturnStatus

Domain Values RS_SUCCESS - service completes successfully

RS_ERROR - service failure due to an error

RS_RESOURCE - service failure due to resources

SecurityInfo

Data Type Definition enum SecurityInfo { Marked , Unmarked } ;

Description Used to determine if a VC is marked for secure comms

Domain Values No special values are associated with this parameter.

SecurityRating

Data Type Definition struct SecurityRating {

ClassificationLevel classification_level ;
Category security_category ;
} ;
Description

Domain Values No special values are associated with this parameter.

SeekMode

Data Type Definition enum SeekMode {

START_OF_FILE , CURRENT_POSITION , END_OF_FILE
} ;
Description START_OF_FILE: Byte pointer at zero

CURRENT_POSITION: Byte pointer inside the file

END_OF_FILE : Byte pointer at the end of file

Domain Values No special values are associated with this parameter.

ServiceAccessList

Data Type Definition typedef octet ServiceAccessList[MAX_NUMBER_OF_APOS_SERVICES] ;

Description Sorted array of all APOS services mapped onto the index domain of a fixed sized
array of boolean values:

‘true’ means: using the service is allowed.

The relation between the index and the corresponding APOS services is given by the

NATO UNCLASSIFIED 440

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ServiceAccessList

IdentAposService enum type.

MAX_NUMBER_OF_APOS_SERVICES = 54 the number of APOS services. See

data type IdentAposService

Domain Values No special values are associated with this parameter.

SmliMessageId

Data Type Definition enum SmliMessageId {

Request_Lc_Change ,
Lc_Changed ,
Signal_For_Lc_Change ,
Ready_For_Lc_Change ,
Security_Data_Written ,
SM_Config_Complete ,
Distant_Error_Event
} ;
Description Definition of the Alternatives of SMLI Messages.

Domain Values No special values are associated with this parameter.

SmliMessage

Data Type Definition struct SmliMessage {

SmliMessageId unique_message_id ;
SmliMessageParameter message_parameter;
} ;
Description Definition of any SMLI message that may be exchanged between A GSM and its
associated AM.

Domain Values No special values are associated with this parameter.

SmliMessageParameter

Data Type Definition union SmliMessageParameter switch( SmliMessageId ) {

case Request_Lc_Change:
PublicId request_lc_change_event_id ;
case Lc_Changed :
PublicId lc_changed_logical_config_id;
case Signal_For_Lc_Change:
PublicId signal_for_lc_change_logical_config_id;
case Ready_For_Lc_Change:
PublicId ready_for_lc_change_event_id ;
case Security_Data_Written:
unsigned long no_parameter_1;
case SM_Config_Complete:
unsigned long no_parameter_2;
case Distant_Error_Event:
PublicId logical_config_id;

NATO UNCLASSIFIED 441

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

SmliMessageParameter

} ;
Description Definition of parameters of SMLI message

Domain Values No special values are associated with this parameter.

State

Data Type Definition typedef PublicId State;

Description A State which is the new state reached after performing the actions specified in the
state machine.

Domain Values No special values are associated with this parameter.

Switch

Data Type Definition enum Switch { SWITCH_ON , SWITCH_OFF } ;

Description Status of switch

Domain Values No special values are associated with this parameter.

SwitchOp

Data Type Definition enum SwitchOp {

SWITCH_ON, SWITCH_OFF , SWITCH_LIMBO
};
Description The status of a power switch.

Domain Values No special values are associated with this parameter.

SwitchStat

Data Type Definition struct SwitchStat {

long millivolts ;
long milliamps ;
SwitchOp state ;
} ;
Description Describes the state of a switch

Domain Values No special values are associated with this parameter.

SwitchStatus

Data Type Definition struct SwitchStatus {

PublicId switch_id ;

NATO UNCLASSIFIED 442

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

SwitchStatus

SwitchStat status ;
} ;
Description Describes the state of a switch identified with the switch_Id

Domain Values No special values are associated with this parameter.

TcDescription

Data Type Definition struct TcDescription {

PublicId tc_id ;
NetworkDescriptor network_descr ;
// indicates the transfer direction: 'receiver' vs.
'sender'
Bool is_receiver ;
// indicates the transfer mode: 'message' vs. 'streaming'
Bool is_msg_transfer ;
// transfer mode: fragmented or normal. Only for SPM
Bool is_fragmented ;
SecurityRating security_rating ;
// In a Multi-Processor environment: the
// processor that configures this TC
PublicId cpu_id ;
InterfaceType conf_data_type ;
// contains the length of the subsequent variant record
// TcConfigurationData
unsigned long conf_data_size ;
TcConfigurationData conf_data ;
};
Description Due to the TC concept which understands the TC as a Transport Connection that
supplies an end-to-end connection, and the concept that the description should
contain routing information (in the ‘network_descr’), the ‘tc_id’ is no longer unique.
Rather a TC-Description item appears at least twice – once for each end-point – with
the same ‘tc_id’ but different data in the ‘network_descr’ and also in the
‘tc_configuration_data’.

Domain Values No special values are associated with this parameter.

TcConfigurationData

Data Type Definition typedef octet TcConfigurationData[ TC_CONFIG_MAX_LEN ] ;

Description Properties of the TransferConnection: structure and format are implementation

dependent according to NII spec for the ASAAC NW

Domain Values No special values are associated with this parameter.

TcConfigurationDMC

Data Type Definition struct TcConfigurationDMC {

PublicId tc_id_routing ;
PublicId fragment_id ;

NATO UNCLASSIFIED 443

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

unsigned long start_address ;

unsigned long length_1 ;
unsigned long increment_1 ;
unsigned long length_2 ;
unsigned long increment_2 ;
unsigned long length_3 ;
unsigned long increment_3 ;
} ;
Description This structure describing the Distributed Multicast Communication Scheme on
receiving or sending side in the example of the corner turn.

This structure is specific to the SPM and may be included in the union
TcConfigurationData when needed.

On sending side:The tc_id_routing shall route to the receiver, whereas the tc_id of
the TcDescription shall identify the DMC TC from the MOS_sendFragmentedTransfer

On receiving side: The tc_id_routing shall route to the receiver, whereas the tc_id of
the TcDescription may identify the DMC TC from the
MOS_receiveFragmentedTransfer

Domain Values No special values are associated with this parameter.

TC_ConfigurationData

Data Type Definition struct TC_ConfigurationData {

Length configuration_data_length ;
TcConfigurationData configuration_data ;
};
Description A unique value used to describe the configuration parameters of an interface used for
NII communication.

Domain Values No special values are associated with this parameter.

ThreadDescription

Data Type Definition struct ThreadDescription {

PublicId global_pid ;
PublicId thread_id ;// local to Process
CharacterSequence entry_point ;
// In a Multi-Processor environment only : The
// processor that hosts this thread
PublicId cpu_id ;
unsigned long stack_size ;
SecurityRating security_rating ;
};
Description Structure describing a thread

Domain Values No special values are associated with this parameter.

ThreadSchedulingInfo

NATO UNCLASSIFIED 444

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

ThreadSchedulingInfo

Data Type Definition struct ThreadSchedulingInfo {

PublicId global_pid ;
PublicId thread_id ;
octet SchedulingInfo[ OS_SCHEDULING_INFO_SIZE ] ;
};
Description Structure describing the parameters of the scheduling policy.

Data Type of SchedulingInfo is not standardised, it shall be used in accordance with

the utilised operating system implementation

OS_SCHEDULING_INFO_SIZE is determined by the utilised operating system

implementation.

Domain Values No special values are associated with this parameter.

ThreadStatus

Definition enum ThreadStatus {

DORMANT , READY , WAITING , RUNNING
} ;
Description The scheduling status of a thread.

A thread is in dormant state if it is not started or if it has been stopped / terminated.

A thread is in ready state when it is ready for execution.

A thread is in waiting state when waiting for some event to occur (sleep, resume,
semaphore, event) to get ready.

A thread is running if it is currently being executed.

Domain Values Inherent to type definition

Time

Definition struct Time {

long sec ;
long nsec ;
} ;
Description The Time structure includes a 32-bit value for the number of seconds and a 32-bit
value for the number of nanoseconds within the seconds.

Both a negative and positive time can be represented, but both values (sec & nsec)
must have the same polarity unless one is zero.

The value of Time will have only one way of representing it. This means that the
absolute value of the nsec value will be constrained to < 1,000,000,000.

An infinite will be represented by the values:

NATO UNCLASSIFIED 445

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Time

sec = 2^31-1

nsec = 999,999,999

Domain Values sec: -2^31 … 0 … 2^31-1

nsec: -999,999,999 … 0 … 999,999,999

TimedReturnStatus

Definition enum TimedReturnStatus {

TM_SUCCESS , TM_ERROR , TM_TIMEOUT
} ;
Description The timed return value provides information on the successful completion of a APOS
thread service and whether a timeout occurs.

Domain Values TM_SUCCESS - service completes successfully

TM_ERROR - service failure due to an error

TM_TIMEOUT - service failure due to a timeout

TimerResources

Data Type Definition typedef TimerResources {

unsigned long id ;
unsigned long resolution ;
};
Description Timer Resource Description

Domain Values id: Timer id

resolution: Resolution for a timer tick in ns

TimerReturnStatus

Data Type Definition enum TimerReturnStatus {

MOS_TIMER_CALL_OK ,
MOS_TIMER_CALL_FAILED
} ;
Description The service returns the status of the time request

Domain Values No special values are associated with this parameter.

TimeInterval

Definition typedef Time TimeInterval ;

NATO UNCLASSIFIED 446

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Description As the Time definition

Domain Values As time.

TransferDirection

Data Type Definition enum TransferDirection {

TRANSFER_DIRECTION_SEND ,
TRANSFER_DIRECTION_RECEIVE
} ;
Description This defines the direction of data transfers on the TC.

Domain Values No special values are associated with this parameter., implementation dependent.

UseAccessRights

Definition enum UseAccessRights {

READ, WRITE, READWRITE
};
Description Access rights when openning a file

Domain Values No special values are associated with this parameter.

UseConcurrencePattern

Definition enum UseConcurrencePattern {

SHARE, EXCLUSIVE
};
Description SHARE: More than one open allowed

EXCLUSIVE: To be opened for exclusive use

Domain Values No special values are associated with this parameter.

UseOption

Definition struct UseOption {

UseAccessRights use_access ;
UseConcurrencePattern use_concur ;
} ;
Description Option when openning a file.

Domain Values No special values are associated with this parameter.

VcDescription

Data Type Definition struct VcDescription {

PublicId global_vc_id;

NATO UNCLASSIFIED 447

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

VcDescription

unsigned long max_msg_length;

unsigned long max_number_of_buffers;
unsigned long max_number_of_threads_attached;
unsigned long max_number_of_TCs_attached;
// Specifies whether the authentication services shall be
// called by the OS for operations on the VC
SecurityRating security_rating;
SecurityInfo security_info;
VirtualChannelType vc_type;
// In a Multi-Processor environment: the
// processor that creates this VC
PublicId cpu_id;
// If TRUE the message is typed and illegible to the data
// representation
Bool is_typed_message;
octet data_representation_format
[ MAX_DATA_REPRESENTATION ] ;
};
Description Properties of the Virtual Channel.

Domain Values No special values are associated with this parameter.

VirtualChannelType

Data Type Definition enum VirtualChannelType {

// Application VC with a Header
Application_Header_VC ,
// Application VC with no Header
Application_Raw_VC,
OLI_VC
};
Description Defines the type of data going over the selected VC

Domain Values No special values are associated with this parameter.

VcMappingDescription

Data Type Definition struct VcMappingDescription {

PublicId global_pid;
PublicId local_vc_id;
PublicId global_vc_id;
// In a Multi-Processor environment: the
// thread using that VC
PublicId local_thread_id;
// Size of the VC, local to the process
unsigned long buffer_size;
// max number of messages kept in the queue
unsigned long number_of_message_buffers;
// Sender is specified by the value FALSE
// Receiver by the value TRUE
Bool is_reading;
// VC_Properties on the receiving ends:

NATO UNCLASSIFIED 448

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

VcMappingDescription

// ordering characteristics: FIFO vs. LIFO

Bool is_lifo_queue;
// behaviour when queue is full:
// refuse the entry vs. expel the oldest entry
Bool is_refusing_queue;
// priority when inserting in the sender site
queue:0..15
unsigned long Priority;
};
Description The characteristics of a virtual channel port, i.e. the access point inside a process to
the VC. In the case of signal processing environment, also the thread using the port
is to be noted

Domain Values No special values are associated with this parameter.

VcToTcMappingDescription

Data Type Definition struct VcToTcMappingDescription {

PublicId global_vc_id;
PublicId tc_id;
// If FALSE the message is not encoded
// If TRUE the CDR encoding is applied
Bool is_data_representation;
} ;
Description The mapping of a VC onto a TC.

Domain Values No special values are associated with this parameter.

NATO UNCLASSIFIED 449

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

14 Tailoring
The standards described in this document are subject to tailoring for any specific implementation. The
tailoring of the standards shall comply with the matrix described below. The standards are split into
software interfaces, sections of interfaces and individual services. Tailoring may take place at any of
these levels. The matrix defines each of these components and provides details of the compatibility
requirements. This allows a specific implementation to justify the development approach taken. This is
described in terms of the following four classes:

A Mandatory,

B Mandatory unless subject to waiver agreed with the customer,

C Recommended unless justifications are stated for not doing so,

D Optional.

For any particular implementation, this matrix must be completed, with compliance to each entry
being stated in the Compliancy column, either YES or NO being used to indicate this.

Table 70 - Interfaces Compliancy Matrix

Interface Class Compliancy

APOS A

SMOS B

SMBP B

MOS C

SMLI B

GLI B

MLI B

OLI C

Table 71 - Service Compliancy Matrix

Interface Service Group Service Class Compliancy

APOS

Thread Management C

sleep C

sleepUntil C

NATO UNCLASSIFIED 450

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

terminateSelf C

getMyThreadId C

startThread C

suspendSelf C

lockThreadPreemption C

unlockThreadPreemption C

stopThread C

getThreadStatus C

Time Management A

getAbsoluteLocalTime A

getRelativeLocalTime A

Synchronisation C

createSemaphore C

deleteSemaphore C

waitForSemaphore C

postSemaphore C

getSemaphoreStatus C

getSemaphoreId C

createEvent C

deleteEvent C

setEvent C

resetEvent C

waitForEvent C

getEventStatus C

getEventId C

Fault Handling B

logMessage B

NATO UNCLASSIFIED 451

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

raiseApplicationError B

getErrorInformation B

Communication A

sendMessageNonblocking A

receiveMessageNonblocking A

sendMessage A

receiveMessage A

lockBuffer C

sendBuffer C

receiveBuffer C

unlockBuffer C

waitOnMultiChannel B

File Handling C

createFile C

deleteFile C

openFile C

closeFile C

getFileAttributes C

readFile C

writeFile C

createDirectory C

deleteDirectory C

seekFile C

lockFile C

unlockFile C

NATO UNCLASSIFIED 452

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

Power Conversion C

setPowerSwitch C

resetPowerSwitch C

getPowerSwitchStatus C

SMOS

Process and Thread Management B

createProcess B

createThread B

runProcess B

stopProcess B

destroyProcess B

setSchedulingParameters B

getThreadState B

Fault Management B

getError B

activateErrorHandler B

VC Configuration B

createVirtualChannel B

destroyVirtualChannel B

attachChannelTo ProcessOrThread B

detachAllThreadsOf ProcessFromVc B

attachTransferConnection B
ToVirtualChannel

detachTransferConnection B
FromVirtualChannel

Network Configuration B

configureInterface B

createTransferConnection B

NATO UNCLASSIFIED 453

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

destroyTransferConnection B

getNetworkPortStatus B

Security Management C

getPMData C

returnPMData C

getAuditData C

erasePhysicalMemory C

Built-In Test Management B

getPbitResult B

startCbit B

getCbitResult B

startIbit B

GetIbitResult B

CFM Information B

getMyCfmStatus B

getMyCfmInfo B

getMyPeId B

CFM Resources Management B

requestDownloadToCfm B

getRemoteInfo B

Time Management B

configureClock B

attachFederatedClock B

Logging Management B

getLogReport B

writeLog B

readLog B

NATO UNCLASSIFIED 454

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

SMBP

getRootNode B

readNode B

getAttributes B

getChildNodes B

getLength B

item B

RTBP Tree B

MOS

Timer C

getAbsoluteLocalTime B

getRelativeLocalTime B

setupTimer C

startTimer C

stopTimer C

readTimer C

Device Services B

readLogDevice B

writeLogDevice B

Callback Services C

registerCallback C

enableCallback C

disableCallback C

deleteCallback C

BIT B

startCbit B

startIbit B

NATO UNCLASSIFIED 455

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

getCbitResult B

getIbitResult B

getPbitResult B

CFM Resource C

getCfmStatus C

getCfmInfo C

getMyPeId C

getPeInfo C

Communication B

configureInterface B

configureTransfer B

sendTransfer B

receiveTransfer B

receiveNetwork C

sendFragmentedTransfer D

receiveFragmentedTransfer D

ConfigureFragmented Transfer D

destroyTransfer B

getNetworkPortStatus C

NATO UNCLASSIFIED 456

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

Bespoke Extension D

addSEP D

createRegion D

deleteRegion D

detach D

attach D

attachAt D

createVM D

deleteVM D

getMyVM D

createContext D

deleteContext D

switchContext D

enterCriticalSection D

leaveCriticalSection D

SMLI

Request_Lc_Change B

Lc_Changed B

Signal_For_Lc_Change B

Ready_For_Lc_Change B

Security_Data_Written C

SM_Config_Complete C

Distant_Error_Event C

GLI

Load_Configuration B

Configuration_Loaded B

Stop_Configuration B

NATO UNCLASSIFIED 457

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

Configuration_Stopped B

Request_New_CFM C

New_CFM_Allocated C

Deallocate_CFM C

CFM_Deallocated C

Run_Configuration B

Configuration_running B

Start_IBIT B

IBIT_Results B

Fault_Report B

Are_You_Alive B

I_Am_Alive B

RequestSC C

SCResponse C

DH_Send_M C

DH_Send_X C

DH_Send_XimodM C

DH_Send_XjmodM C

RequestKey C

SendKey C

MLI

RequestPBITResult B

RequestCfmStatus B

RequestCFMInfo B

TestMessage B

LoadImage B

LoadRoutingTable B

NATO UNCLASSIFIED 458

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Interface Service Group Service Class Compliancy

LoadTimeConfiguration B

RequestIBITStart B

RequestIBITResult B

RequestAGT C

ReadyforALTSynchro C

RequestALT C

RequestAGTALT C

LoadNetworkConfiguration B

RequestNetworkStatus B

LoadPowerSwitches Configuration B

RequestPowerSwitches Status B

TC Header C

OLI

RequestReadFile C

ReplyReadFile C

RequestRemoteMLIFile Download C

ReplyRemoteMLIFile Download C

VC Header C

Graphics

Tag Language C

NATO UNCLASSIFIED 459

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Annex A AGL
(Normative)

A.1. The Concept

DP DP GP
App App

VC Mgmt VC Mgmt

AGL Interpreter

Rendering Software
Comms Comms Graphics
Services Services Accelerator

AGL

Figure A.1 - Graphics Concept

To enable a graphics application, hosted on a general-purpose processor, to transmit graphical

commands to a graphic engine/accelerator, a transport mechanism for data transferral is required.
When defining this transport mechanism COTS technology has been used as a baseline i.e. in a
workstation environment, for example using OpenGL, this transport mechanism would normally be
achieved by using the OpenGL extensions to X windows (GLX). Here we propose a simple tagging
mechanism, which defines a unique identifier for the graphical, commands, in effect a GLX.

A.2. Graphical Command Set

A.2.1. Overview
In the tables below, tag and enumeration values are included for the ASAAC graphical command set.
This is based on OpenGL Version 1.1 command set (see reference [8]). OpenGL is a large and
complex graphics library in comparison to the graphics functionality currently used in aircraft display
systems, and for most of these displays (especially those in the flight deck), only a fraction of the
OpenGL commands would be required. Therefore, this document defines a ‘minimum set’ of graphical
commands/functions necessary for current and projected future display systems. The aim being to
reduce LCC by reducing the overall complexity, and therefore cost of the GPM, while still ensuring it
as the required complexity to fulfil the full range of requirement encountered in avionic application.

It is suggested that the complexity of the tag language be kept to a minimum in the following ways
and/or the following certification issues be addressed: -

System requirements – Only commands representing functionality identified as being required (or
likely to be required) as part of aircraft displays should be implemented. However it is admitted that
this task is difficult because future requirements are somewhat fluid.

NATO UNCLASSIFIED 460

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Data formats – COTS graphical languages, such as OpenGL, support many different data types and
formats, both in its interface and in internal conversions. This allows programming flexibility and
provides maximum support for porting legacy applications. However, some of the formats and
conversions introduce inefficiency, making execution times much less deterministic. Supporting many
data formats also introduces a large volume of code, most of which may never be used in a particular
system. It is therefore suggested that AGL identify only the efficient data formats and types which
meet system requirements and are likely to be directly supported by hardware acceleration.

Efficiency – It may be desirable to remove functionality for certain systems to increase throughput. For
example 3D transforms, depth buffering and clipping planes are not required for 2D display systems.
However the CFM inter-change requirements of an IMA system is unlikely to allow this.

Implementation Dependencies – most COTS graphical languages allow many features to be

implementation dependent (for example anti-aliasing is not mandatory, and in OpenGL queries can be
made using glGet* on attributes such as maximum line thickness). For a standardised interface, the
required functionality should be mandated. Therefore, commands to interrogate capabilities are
redundant.

A.2.2. Command Listings

The tables below attempt to categorise the AGL (and the OpenGL commands they where based
upon) according to the broad functionality they represent. The associated notes table defines these
categories and indicates which ones should be implemented, and those that are not necessarily
required. For the OpenGL commands, the same notation is used as defined in reference 3.

Corresponding Library names: gl – Graphics Language / al – Auxiliary Library / vl – Video Library

Table A.1 - ASAAC Graphics Language

AGL Function Name Corresponding Library Names Required for

2D 3D I E CC GF TM IC A V CV

AGL_BEGIN glBegin X

AGL_END glEnd X

AGL_VERTEX2F glVertex2{sifd}{v} X X

AGL_VERTEX3F glVertex3{sifd}{v} X

AGL_VERTEX4F glVertex4{sifd}{v} X

AGL_RECT glRect{sifd}v X X

AGL_ROTATE glRotate{fd} X X

AGL_TRANSLATE glTranslate{fd} X X

AGL_SCALE glScale{fd} X X

AGL_MULT_MATRIX glMultMatrix{fd} X

AGL_LOAD_MATRIX glLoadMatrix{fd} X

AGL_LOAD_IDENTITY glIdentity X

NATO UNCLASSIFIED 461

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AGL Function Name Corresponding Library Names Required for

2D 3D I E CC GF TM IC A V CV

AGL_MATRIX_MODE glMatrixMode X

AGL_PUSH_MATRIX glPushMatrix X

AGL_POP_MATRIX glPopMatrix X

AGL_DEPTH_RANGE glDepthRange X

AGL_VIEWPORT glViewport X

AGL_COLOR_3F glColor3{bsifd usui}{v} X

AGL_COLOR_3UB glColor3{ub}{v} X X

AGL_SHADE_MODEL glShadeModel X

AGL_CLIP_PLANE glClipPlane X X

AGL_RASTER_POS2F glRasterPos2{sifd}{v} X

AGL_RASTER_POS3F glRasterPos3{sifd}{v} X

AGL_RASTER_POS4F glRasterPos4{sifd}{v} X

AGL_BITMAP glBitmap X

AGL_POINT_SIZE glPointSize X

AGL_LINE_WIDTH glLineWidth X

AGL_LINE_STIPPLE glLineStipple X

AGL_CULL_FACE glCullFace X

AGL_READ_BUFFER glReadBuffer X

AGL_READ_PIXELS glReadPixels X

AGL_DRAW_PIXELS glDrawPixels X

AGL_COPY_PIXELS glCopyPixels X X

AGL_PIXEL_ZOOM glPixelZoom X X

AGL_TEX_PARAMETER glTexParameter{if}{v} X

AGL_TEX_ENV glTexEnv{if}{v} X

AGL_TEX_COORD1F glTexCoord1{sifd}{v} X X

AGL_TEX_COORD2F glTexCoord2{sifd}{v} X X

NATO UNCLASSIFIED 462

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AGL Function Name Corresponding Library Names Required for

2D 3D I E CC GF TM IC A V CV

AGL_TEX_COORD3F glTexCoord3{sifd}{v} X

AGL_TEX_COORD4F glTexCoord4{sifd}{v} X X

AGL_TEX_GEN glTexGen{ifd}{v} X X

AGL_TEX_IMAGE1D glTexImage1D X

AGL_TEX_IMAGE2D glTexImage2D X

AGL_SCISSOR glScissor X

AGL_STENCIL_FUNC glStencilFunc X

AGL_STENCIL_OP glStencilOp X

AGL_DEPTH_FUNC glDepthFunc X

AGL_BLEND_FUNC glBlendFunc X X

AGL_CLEAR glClear X

AGL_CLEAR_COLOR glClearColor X

AGL_CLEAR_DEPTH glClearDepth X

AGL_CLEAR_STENCIL glClearStencil X

AGL_DRAW_BUFFER glDrawBuffer X

AGL_STENCIL_MASK glStencilMask X

AGL_NEW_LIST glNewList X

AGL_END_LIST glEndList X

AGL_DELETE_LISTS glDeleteLists X

AGL_CALL_LIST glCallList X

AGL_GEN_LISTS glGenLists X

AGL_IS_LIST glIsList X

AGL_LIST_BASE glListBase X

AGL_ENABLE glEnable X

AGL_DISABLE glDisable X

AGL_FINISH glFinish X

NATO UNCLASSIFIED 463

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

AGL Function Name Corresponding Library Names Required for

2D 3D I E CC GF TM IC A V CV

AGL_FLUSH glFlush X

AGL_HINT glHint X

AGL_GET_ERROR glGetError X

AGL_END_OF_BUFFER Buffer management X

AGL_OPEN alOpen X

AGL_MAKE_CONTEXT alMakeContext X

AGL_MAKE_WINDOW alMakeWindow X

AGL_ATTACH alAttach X

AGL_SWAP_BUFFERS alSwapBuffers X

AGL_BUFFERS_SWAPPED alBuffersSwapped X

AGL_GET_FRAME_USE alGetFrameUse X

AGL_WAIT_FOR_SWAP alWaitForSwap X

AGL_VLENABLE vlEnable X

AGL_VLDISABLE vlDisable X

AGL_VBLEND_FUNC vlBlendFunc X

AGL_VLVIDEO_STANDARD vlVideoStandard X

AGL_VLVIDEO_IN vlVideoIn X

AGL_VLVIDEO_PORT vlVideoPort X

AGL_VLVIDEO_POS vlVideoPos X

AGL_VLVIDEO_ZOOM vlVideoZoom X

AGL_VLVIDEO_PARAM vlVideoParam X

AGL_VLVIDEO_IMAGE vlVideoImage X

AGL_VLGET_ERROR vlGetError X

TABELLE

NATO UNCLASSIFIED 464

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Table A.2 - Keys Referred to in Table A.1

Key Required for ASAAC

2D Essential for generating 2D displays (e.g. cockpit displays)

3D Essential for generating 3D displays (also requires all 2D)

I Image processing

E Essential for efficiency or fine control of operation

CC Complex shape cut outs and masking

GF Select Gouraud shading

TM Texture mapping (Mipmapping functions not to be demonstrated)

IC Image composing and special effects

A Auxiliary commands to control graphics resources, buffers etc.

V Commands to control video hardware

CV Cutaway views (slice through a 3D object)

A.2.3. Auxiliary Library (AL) Definition

The following commands are not aimed at graphical image creation but are required to identify, assign
and control graphics resources. Although a window creation command is included, a window manager
is not required. The windowing may be restricted to static screen partitioning.

Table A.3 – Auxiliary Functions

Function Name Description

alAttach Make the connection between a context and a window

alBuffersSwapped The return parameter indicates the state of the buffer swap. When an alSwapBuffers command
is issued, a buffer swap request is made, and is pending until the swap occurs. A return value of
FALSE indicates the swap has not yet occurred.

alGetFrameUse The return parameter gives the percentage of frame usage (drawing of graphics) in the current
frame at the selected frame rate. A value greater than 100% signifies overframing.

alMakeContext Create a context associated with the graphics resource

alMakeWindow Create a window using a graphics resource

alOpen Begin communication with a graphics resource (in ASSAC a particular GPM)

alSwapBuffers Requests the exchange of the front and back framebuffers. The exchange does not occur
immediately, but shall take place at the end of the frame.

alWaitForSwap Waits for the framebuffer swap to occur. This takes place at the end of the frame. The end of the
frame may be defined by a vertical retrace, or its equivalent for the particular type of display
being driven. The end of frame may be synchronised with external timings and/or video.

NATO UNCLASSIFIED 465

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Function Name Description

The return parameter gives the percentage of frame usage (drawing of graphics) in the current
frame at the selected frame rate. A value greater than 100% signifies overframing.

A.2.4. Video Library (VL) Definition

The following commands control the Video subsystem. The library has been designed to be similar in
style to the Graphics Library.

Table A.4 – Video Library Functions

Function Name Description

vlBlendFunc Selects the blending function (mix) performed. The parameters sfactor, dfactor define the
blend operations to be performed according to the following equation:

s*S + d*D

Where S and D are the RGB triplets of the framebuffer and video/fill color channels
respectively, and the s, d parameters are defined as follows (Alpha is the intensity component
sourced from the framebuffer):

vlEnable, vlDisable Enables/disables the capability identified by cap. The parameters values can be as follows:

VL_ANALOGUE: Enables the analogue display channel. Defaults to enabled.

VL_DIGITAL: Enables the digital display channel. Defaults to disabled.

VL_VIDEO_INPUT: Enables the video input to the mixer. When disabled the fill color is used
instead of video. Defaults to disabled.

VL_GRAPHICS: Enables the graphics input to the mixer. Defaults to enabled.

VL_RED: Enables the red channel DAC. Defaults to enabled.

VL_GREEN: Enables the green channel DAC. Defaults to enabled.

VL_BLUE: Enables the blue channel DAC. Defaults to enabled.

VL_ALPHA_OVERLAY: Enables the overlay display of an image stored in the alpha planes
of the framebuffer. Defaults to disabled

vlVideoStandard - Associates the video standard identified by pname with the source identified by source. The
pname parameters are as follows:

VL_525_CCIR: CCIR standard 525 line video.

VL_625_CCIR: CCIR standard 625 line video.

vlVideoAspectRatio - Selects the video aspect ratio by dividing width by height and matching the ratio to
capabilities of the hardware. e.g. 1/1, 768/512 (=4/3).

vlVideoIn - Selects the input video source identified by source.

vlVideoPort - Selects the size and position of a video window. The video to which the window applies is
specified by source.

vlVideoPos - Specifies the x and y current position within the video image. This allows a video image to be
panned around within a video window. The video to which the position applies is specified by

NATO UNCLASSIFIED 466

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

Function Name Description

source.

vlVideoZoom - Specifies the x and y zoom factors by which to scale a video image. The video to which the
scaling applies is specified by source. Parameters xfactor and yfactor are clamped to the
implementation dependent limits of resize capable.

vlVideoParam - Specifies video parameters. The video to which the parameters apply is specified by source.

vlVideoImage - Specifies video parameters. Specifies a video image.

vlGetError - Returns the value of the error flag.

A.2.5. Texture Mapping Constraints

The texture map data formats are constrained to those likely to require little or no conversion before
being used by texture mapping hardware. This is important for efficiency if the texture image is
frequently updated (e.g. video data). The image data type is therefore limited to unsigned bytes. No
conversion to RGBA or pixel transfer function is performed on the image, so the data format should
comply with the internal format as shown in the table below:

Table A.5 – Texture Formats

Internal format Format

GL_ALPHA8 GL_ALPHA or GL_RED

GL_LUMINANCE8 GL_LUMINANCE or GL_RED

GL_LUMINANCE4_ALPHA4 GL_LUMINANCE_ALPHA *

GL_LUMINANCE8_ALPHA8 GL_LUMINANCE_ALPHA

GL_INTENSITY GL_RED

GL_INTENSITY8 GL_RED

GL_R3_G3_B2 GL_RGB *

GL_RGB4 GL_RGB *

GL_RGB5 GL_RGB *

GL_RGB8 GL_RGB

GL_RGBA4 GL_RGBA *

GL_RGB5_A1 GL_RGBA *

GL_RGBA8 GL_RGBA

Those marked with * require conversion from 8-bits to the type defined by internal Format, so
although reducing the required texture memory, they may take longer to load. Note that the internal
Format is only a suggestion as to how the image should be stored for some of the types.

NATO UNCLASSIFIED 467

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

All mipmap levels in a set of textures shall be of the same format (i.e. all share the internal Format
and border settings of texture level 0), and each level reduce in size to ¼ area of the previous level.
This assists in determining the memory requirements for a full set of mipmap textures.

The maximum texture size should be limited to 1024*1024 texels (1026*1026 including border). This
sets the number of mipmap levels to 10, and requires approximately 6 Mbytes of texture memory (at
32 bits per texel). Note that increasing the texture size (say to 2048*2048 almost quadruples the
memory requirement. Hardware sometimes uses the same graphics memory for texture, stencil,
depth and perhaps frame buffers, so the texture requirements should be defined to be consistent with
the other contenders for this type of memory. An example allocation might be:

- Depth Buffer: 1280*1024@16bpp = 2.5 Mbytes,

- Stencil Buffer: 1280*1024@8bpp = 1.25 Mbytes,

- Frame Buffer: 2*1280*1024@32bpp = 10 Mbytes (double buffered),

- Texture Memory: 1024*1024 .. 1*1 @32bpt = 6 Mbytes,

- Total: ~ 20 Mbytes.

If 32 Mbytes of graphics memory were fitted, the above allocation allows some scope for auxiliary
buffers or expanding depth buffer depth.

A.2.6. Display Frame and Synchronisation

To produce real time animated graphics, the application software is usually organised as part of a
display frame using some form of double buffering of the display.

The display frame is governed by the display output stage of the graphics system. With a double
(frame buffer) buffered system, graphics are drawn to the non-displayed (back) buffer, and then a
buffer swap is performed (exchanging the front and back buffers) to produce a display. This is done
on a cyclic basis at a high rate to provide the smooth animation required.

An application running as a remote producer of graphics commands cannot run at a faster rate than
the graphics consumer, and is therefore limited by the rate of the consumer. Synchronisation and
control of display frame rated can be achieved by use of the alSwapBuffers and alWaitForSwap
commands.

A.2.7. Command Responses and Delays

Several of the commands (tags) require a response from the graphics system, either by completion of
the command or the return of data. Commands in this category are identified in the command list
table by the note “SYNC”. These commands may take a significant time to complete (for example
waiting for graphics rendering to complete or the end of the display frame). The scheduling system on
the graphics producer (applications) processor needs to be aware of this and manage processing
time appropriately (perhaps by scheduling other tasks).

NATO UNCLASSIFIED 468

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NATO UNCLASSIFIED 469

 NATO UNCLASSIFIED

STANAG 4626 (Part II)

(Draft 1)

NATO UNCLASSIFIED i
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

ASAAC Phase II Stage 2

Rationale for Software Standards

Issue 01

IPR_Category: 1
in accordance with Document n°25/SPAé/ST/AVI/IN, dated 04/08/99

Document N° : ASAAC2-STA-32410-002-SWG

Prepared by : Software Working Group

Issue Date : 26/12/19

Pages : 499

NATO UNCLASSIFIED 1
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

Table of Contents
1 Introduction .............................................................................................................................. 4
1.1 Scope of this Document.......................................................................................................... 4
1.2 Work Package Objectives ....................................................................................................... 4
1.3 Software Standards ................................................................................................................. 4
1.4 Abbreviations ........................................................................................................................... 5
2 Related Documents ................................................................................................................. 6
3 ASAAC Software Architecture ............................................................................................... 7
3.1.1 Software Architecture Overview ............................................................................................ 7
4 Software Components ............................................................................................................. 9
4.1 Functional Applications .......................................................................................................... 9
4.1.1 Justification for Functional Applications.............................................................................. 9
4.2 Application Management ........................................................................................................ 9
4.2.1 Justification for Application Management ............................................................................ 9
4.3 Operating System .................................................................................................................... 9
4.3.1 Justification for Operating System ........................................................................................ 9
4.4 Generic System Management .............................................................................................. 10
4.4.1 Justification for Generic System Management .................................................................. 10
4.5 Runtime Blueprints ................................................................................................................ 11
4.5.1 Justification for Runtime Blueprints ................................................................................... 11
4.6 Module Support Layer ........................................................................................................... 11
4.6.1 Justification for Module Support Layer .............................................................................. 11
5 Direct Interfaces ..................................................................................................................... 12
5.1 APOS: Application to Operating System Interface ............................................................ 12
5.1.1 Justification for APOS .......................................................................................................... 12
5.1.2 Justification for Identified Services ..................................................................................... 12
5.2 MOS: Module Support Layer to Operating System Interface ............................................ 13
5.2.1 Justification for MOS ............................................................................................................ 13
5.2.2 Justification for Identified Services..................................................................................... 13
5.3 SMOS: System Management to Operating System Interface............................................ 13
5.3.1 Justification for SMOS .......................................................................................................... 13
5.3.2 Justification for Identified Services ..................................................................................... 14
5.4 SMBP: System Management to Blueprint Interface ........................................................... 14
5.4.1 Justification for SMBP .......................................................................................................... 14
5.4.2 Justification for the RTBP Grammar ................................................................................... 15
5.4.3 Justification for Identified Services..................................................................................... 15
6 Logical Interfaces .................................................................................................................. 16
6.1 OLI: Operating System Logical Interface ............................................................................ 16
6.1.1 Justification for OLI ............................................................................................................... 16
6.1.2 Justification for OLI Services ............................................................................................... 16
6.2 GLI: Generic System Management Logical Interface ........................................................ 16
6.2.1 Justification for GLI ............................................................................................................... 16
6.2.2 Justification for GLI Services ............................................................................................... 16
6.3 SMLI: System Management Logical Interface .................................................................... 17
6.3.1 Justification for SMLI ............................................................................................................ 17
6.3.2 Justification for SMLI Services ............................................................................................ 17
6.4 MLI: Operating System Logical Interface ............................................................................ 17
6.4.1 Justification for MLI .............................................................................................................. 17
6.4.2 Justification for MLI Services .............................................................................................. 18
7 Conclusion ............................................................................................................................. 19

NATO UNCLASSIFIED 2
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

List of Figures
Figure 1 - ASAAC Three Layer Software Architecture .............................................. 7

Figure 2 - The Software Architecture Model ............................................................. 7

NATO UNCLASSIFIED 3
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

1 Introduction

1.1 Scope of this Document

This document is produced under the contract ASAAC Phase II Contract [7]. It is the second
deliverable associated with Work Package 32410, “Final Draft of Proposed Standards for Software”
and is the Rationale report for this Standard, which is included in Poste 3D of the contract.

1.2 Work Package Objectives

The objective of work package WP32400 is to produce the final draft of the Standards that define an
IMA system, its architecture, software and the Common Functional Modules (CFMs) to operate within
it.

In order to obtain a set of software standards for an IMA core-processing system, it is not sufficient
merely to define a set of standards without giving a justification as to their selection or their content,
which is the objective of this document.

1.3 Software Standards

During ASAAC a common software model based on the concept of a layered software architecture
has been defined. Within this model, the layers are separated by standardised interfaces in order to
provide independence of these layers. Interfaces encapsulate a lower software layer and provide a
type of virtual machine view to a higher software layer. In this context, each interface provides a
generic set of services and resources. This supports the following top-level requirements as identified
in [8]:

Number Requirement

TLR_2 Modules Applicable to Wide range of platforms

TLR_3.1 Re-use of Software

TLR_3.2 Module replaceable at first line

TLR_3.3 No base and depot level maintenance

TLR_3.4 Deferred maintenance

TLR_3.5 Comprehensive BIT and Testability

TLR_8 Interoperability

TLR_9 Interchangeability

TLR_10 Technology Transparency

TLR_11 Use of Commercial components, technologies and processes

TLR_12 Maximise digital processing of functions

NATO UNCLASSIFIED 4
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

Number Requirement

TLR_13.1 General system requirements and performance

TLR_13.2 Sensors and sub-system

TLR_13.3 Interface definitions

TLR_13.4 Criticality of functions

TLR_14.1 Growth Capability

TLR_14.2 Modularity and configurability

TLR_15 Certification and qualification

TLR_16 Security

TLR_17 System management

1.4 Abbreviations
API Application Programming Interface
AC Aircraft
APOS Application to Operating System interface
ASAAC Allied Standard Avionics Architecture Council
BIT Built in Test
CFM Common Functional Module
GLI Generic system management Logical Interface
GSM Generic System Management
HW Hardware
IA Integration Area
ITM Integrated Test and Maintenance
MLI Module Logical Interface
MMM Mass Memory Module
MOS MSL to Operating System interface
MSL Module Support Layer
OLI Operating system Logical Interface
OS Operating System
OSL Operating System Layer
PCM Power Conversion Module
PE Processing Element
RE Resource Element
SMBP System Management to Blueprint interface
SMLI System Management Logical Interface
SMOS System Management to Operating System interface
SW Software
TLR Top Level Requirement
VC Virtual Channel

NATO UNCLASSIFIED 5
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

2 Related Documents
A) References to published standards

None.

B) References to standards in preparation

[2] ASAAC2-STA-32410-001-SWG Final Draft of proposed Standards for

Issue 01 Software
[3] ASAAC2-STA-32420-001-HWG Final Draft of proposed Standards for
Issue 01 Communications / Network

[4] ASAAC2-STA-32430-001-HWG Final Draft of proposed Standards for

Issue 01 Common Functional Module

[5] ASAAC2-STA-32440-001-HWG Final Draft of proposed Standards for

Issue 01 Packaging

[6] ASAAC2-STA-32460-001-CPG Final Draft of Proposed Standards for

Issue 01 Architecture

C) References to other documents

[7] N°26/97/SPAé/ST/AVI du 26/06/97 Clauses Techniques Annexées au marché

97/86.066, ASAAC Phase II
[8] ASAAC2-RPT-52100-010-TMG-I01 Stage 1 Final Report
Issue 01
[9] ASAAC-STA-32420-002-HWG Rationale Report for Communications /
Issue 01 Network Standards

[10] ASAAC-STA-32430-002-HWG Rationale Report for Common Functional

Issue 01 Module Standard

D) References to documents from other organizations

None.

NATO UNCLASSIFIED 6
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

3 ASAAC Software Architecture

3.4.1 Software Architecture Overview

The ASAAC Software Architecture is based on a three-layer stack with each layer being described in
terms of it dependency/independency on both the aircraft system and the underlying hardware as
shown by Figure 2.

Application Layer Aircraft Dependent

Hardware Independent

APOS
Aircraft Independent
Operating System Layer
Hardware Independent

MOS
Aircraft Independent
Module Support Layer
Hardware Dependent

Figure 2 - ASAAC Three Layer Software Architecture

The full ASAAC Software Architecture is more complex than that shown in Figure 2 and includes a
number of standardised interfaces, both direct and logical, and a number of software components that
have a standardised functional behaviour.

Application Layer Application Layer

Func Func App App Func Func

App App Mgr Mgr App App
SMLI SMLI

APOS APOS
AP S S AP
OS M Run Time Run Time M OS
B Blue Prints Blue Prints B
P P
Operating SM GSM GSM SM Operating
OS GLI OS
System System
OLI
Operating System Layer Operating System Layer
MOS MOS

Module Network Network Module

MLI
Resources Interface Unit Interface Unit Resources

Module Support Layer Module Support Layer

MPI
MPI

Network
Interconnect
Fabric

Figure 3 - The Software Architecture Model

NATO UNCLASSIFIED 7
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
Table 6 shows the standardised components that comprise the full ASAAC Software Architecture and
the interfaces between them. The interfaces in the application domain are not standardised, while the
interfaces in the domain of OSL and MSL are standardised. The components and their relationship are
shown in Figure 3 as well.

Table 6 - ASAAC Software Architecture Components and Interfaces

from (rows) Application

Application
Functional

Manager
\

RTBP
GSM

MSL
OS
to (columns)

not not
Functional
standardis standardis APOS null null null
Application
ed ed

not not
Application
standardis standardis APOS SMLI null null
Manager
ed ed

OS null null OLI null null MOS

GSM null SMLI SMOS GLI SMBP null

RTBP null null null null null null

MSL null null null null null MLI

The remaining sections in this document provide the rationale behind including each of these
components within the ASAAC Software Architecture.

NATO UNCLASSIFIED 8
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

4 Software Components

4.4 Functional Applications

The term "Functional Applications" relates to all functions that handle the processing of operational
data, e.g.

• Radar Applications,
• Mission Management,
• Stores Management,
• Vehicle Management System,
• Communication, Navigation and Identification.

4.4.1 Justification for Functional Applications

These are the applications that comprise the operational functionality of the system.

4.5 Application Management

Application Management covers that aspect of system management whose purpose is to control the
mission moding selection and the selection of modes within a particular mission.

4.5.1 Justification for Application Management

Some aspects of system management are directly related to the aircraft or mission being flown so,
according to the definition of the three layers in Figure 2, cannot reside in the Operating System Layer.
Thus, application management becomes another instance of a functional application, but one that can
communicate directly with the Generic System Management resident in the OSL and thus either
instigate mode changes during a mission or respond to changes in available resources due to faults
and failures.

4.6 Operating System

The Real-Time OS provides the particular part of OSL functionality that controls the real-time
behaviour of the Processing Element and its associated resources.

4.6.1 Justification for Operating System

The Real-time Operating System provides the particular part of OSL functions the management of PE
resources, especially the handling the real-time scheduling of threads. In detail, it comprises the
following functionality:

• Process Management
Responsible for assigning memory segments to processes and ensuring integrity of
memory segments.
• Communication Services

NATO UNCLASSIFIED 9
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
Responsible for the Virtual Channel (VC) communication
• Synchronisation Services
Responsible for the control of semaphores and events
• Time Management
This includes the management of:
5 Time-out periods for blocking services
6 The time interval between periodic threads
• Thread Management
This includes the management of:
7 Scheduling
8 State transition
9 Deadline overrun detection
10 Thread queuing discipline
• Error Handling
Responsible to detect PE errors and to provide the error reporting functions.
• File Management Services

4.4 Generic System Management

The GSM provides the basic functions that enable the system management at the RE, IA and AC
levels within a system to control the resources and behaviour of the ASAAC core.

4.4.1 Justification for Generic System Management

The functionality offered by the GSM is generic and therefore this function resides in the Operating
System Layer of the basic three-layer model and comprises:

• Health Monitoring
Required to detect the occurrence of faults.
• Fault Management
Required to identify, localise and contain any faults that occur during a mission as
well as log data for maintenance purposes.
• Configuration Management
Required to initialise and shutdown a system as well as performing reconfiguration
due to the receipt of mode change requests or failures.
• Security Management
Required to protect the integrity, availability and confidentiality of ‘protectively marked'
data as it is uploaded to, downloaded from and processed within a system.

NATO UNCLASSIFIED 10
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
4.5 Runtime Blueprints
The RTBP contain the data (e.g. process description, routing information, fault management data)
required to configure and manage the core processing on which it is hosted.

4.5.1 Justification for Runtime Blueprints

The system configuration is described in terms of configuration states and transitions between
configuration states. A configuration state is characterised as each stable state of a GSM entity (i.e. an
individual AC, IA or RE level GSM function).

It is ultimately the Runtime Blueprints that provide the data that describe these states and the
transitions between them. This data comprises:

• Configuration Description
Defines a configuration status.
• Transition Definition
Provides a sequence of actions to be performed in order to transfer a GSM entity
from one configuration status into another configuration status.
• Configuration Data
Define the description of atomic configuration items.
• Fault Management Description
Defines the fault management policy and corrective actions.
• Security Management Description
Defines the security management policy.

4.6 Module Support Layer

The Module Support Layer (MSL) implements the Module to Operating System Interface (MOS),
which encapsulates the hardware architecture of a given Common Functional Module (CFM).

4.6.1 Justification for Module Support Layer

The Module Support Layer encapsulates the details of the underlying hardware and provides generic,
technology independent access to low-level resources. The encapsulation is provided using defined
services. These services comprise communication and board resource services.

In case an operating systems needs additional optional MOS services, the MOS is defined in a way
that there is no need for the layer above to have any knowledge about the implementation of the HW
provided of the MOS interface.

NATO UNCLASSIFIED 11
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

5 Direct Interfaces

5.1 APOS: Application to Operating System Interface

5.1.1 Justification for APOS

The Application to Operating System Interface provides the Functional Application Software developer
with the following services:

• Communication Services (Virtual Channels)

• Time Services
• Thread Control Services
• Intra-process Synchronisation Services (Semaphores, Events)
• Fault Reporting Services
• File Handling Services
• Power Control Services
Thus, the APOS establishes means to couple applications to the ASAAC core and allow them to share
all system properties provided by the ASAAC software architecture.

5.1.2 Justification for Identified Services

The ASAAC software architecture presents an increasing level of abstraction from the resources level
towards the higher layers. This is especially reflected by the concept of virtual channels for all
communications between processes and the use of configuration information contained in the run-time
blueprints. Because all interactions with system management are restricted to the SMLI, all the APOS
services are provided by Operating System solely. The justification for the APOS services is:

• Communication Services
The use of virtual channels and the blueprint information enforces the modularity and
re-usability of application functions as virtual channels provide applications a way to
communicate transparent to the underlying resources and the kind and number of co-
operating application functions.
• Time Services
The time services provide basic time information on module, system and global time
in order to facilitate time synchronisation within a process, between application
functions and with external events.
• Thread Control Services
Threads represent the temporal characteristics of an application. The need to
prioritise processing within a single process justifies the utilisation of multiple threads.
• Synchronisation Services
The synchronisation services are required in order to support the implementation of
multi-threaded algorithms.

NATO UNCLASSIFIED 12
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
• Error Handling Services
Support the handling of errors in the application domain and synchronisation with the
handling of errors and faults in the domain of the ASAAC core.
• File Handling Services
Provide access to files on MMM.
• Power Control Services
Provide control of power switches on PCM.

5.2 MOS: Module Support Layer to Operating System Interface

5.2.1 Justification for MOS

The Module to Operating System Interface presents a common set of standardised low-level services
to the operating system. Thus, the MOS encapsulates the underlying processing hardware and in this
context provides transparency to the operating system layer.

It is important to mention, that the set of MOS services supports all ASAAC system properties required
by the Operating System to provide sufficient services to the applications via the APOS and to the
System Management functions via SMOS.

The MOS interface also provides for services and their behaviour, which allow the Operating System
Layer to be implemented and ported on an arbitrary hardware platform. Therefore, the MOS is divided
into a ‘Core MOS’ and ‘Optional MOS’ sub-sets. Additionally there are module specific subsets of
MOS services for PCM and MMM modules.

5.2.2 Justification for Identified Services

The MOS services have been divided into three groups of services:

• Processor Support Services

The Processor Support Services define an interface, which encapsulates processor
dependent features such as execution context handling.
• Board Services
The Board Services define an interface, which encapsulate board specific device
accesses.
• Communication Services
The Communication Services define an interface, which encapsulate network
services such as receiving and sending messages on Transfer Connections.

5.3 SMOS: System Management to Operating System Interface

5.3.1 Justification for SMOS

The SMOS, encapsulated within the OSL, describes the services provided by the Operating System to
the Generic System Management. It establishes a bound between the resource management

NATO UNCLASSIFIED 13
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
functions that are provided by the operating system, and the system management functions that are
provided by the Generic System Management.

The SMOS interface ensures the technology transparency for the operating system.

5.3.2 Justification for Identified Services

The SMOS services provide an interface between generic system management and the operating
system for command, control, and configuration purposes. To cope with the system management the
SMOS provides services necessary to 'instantiate' a system according to the information contained in
the blueprints:

• Resource Configuration Control Services

These services provide control of the standardised configuration items for a particular
PE. They include the set-up of processes, threads, their associated scheduling
information, virtual channels, transfer connections network ports and clock in
accordance with the RTBP configuration data.
• Control of remote Modules
This includes the set-up of the network, the initialisation and the monitoring of remote
modules in accordance with the RTBP configuration description.
• BIT Management Services
Provide the control and access on local BIT functions required for the fault
management within the ASAAC core and ITM activities.
• CFM Information Services
Provide status and characteristics of the local module.
• Fault and Logging Management Services
Provide services to complement the GSM fault management function.
• Security Management Services
Provide services to complement the GSM security management function.
The SMOS provides for a replication of MOS services, because context switching, scheduling and the
control of access rights are dealt with within the OS. Because the Generic System Management
consists of a set of processes under the control of the OS, no direct access to the MOS is feasible.
Therefore those replicated services allow the GSM access to the relevant MOS services through the
SMOS.

5.4 SMBP: System Management to Blueprint Interface

5.4.1 Justification for SMBP

The standardisation of this interface separates the generic GSM functions from the system specific
blueprints data.

The SW standard (see [2]) defines the grammar, but not the format of the Runtime Blueprints. The
SMBP interface hides the project specific Runtime Blueprint implementation from the GSM. It

NATO UNCLASSIFIED 14
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
assumes that the implementation can be mapped to a tree and can be parsed with the standard
operations of a tree.

5.4.2 Justification for the RTBP Grammar

The standardised RTBP grammar provides the basic tree of blueprint data required for every ASAAC
core. This set of data is therefore open for project specific extension of the RTBP information.

5.4.3 Justification for Identified Services

The SMBP services are independent from the contents of the RTBP but only dependent on the tree
grammar of the RTBP referring to a single root. There are two kinds of services:

• Tree Traversal Services

Navigate within the structure of runtime blueprint data.
• Information Access Services
Access the configuration data.

NATO UNCLASSIFIED 15
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

6 Logical Interfaces

6.4 OLI: Operating System Logical Interface

6.4.1 Justification for OLI

The OLI addresses the interaction between different instances of the Operating System.

It defines the necessary aspects and protocols necessary to promote interoperability of the modules
with one another and the provision of access to MMM localised files.

6.4.2 Justification for OLI Services

The OLI covers:

• Data Equivalence Services

The OLI provides the information required for the translation between the
standardised network representation of virtual channel data and the data
representation used by the processes of the local PE.
• Remote File Access
The OLI provides access to files required by the Generic System Management for
process initialisation and handles requests for module initialisation. It ensures
transparency with respect to the location of a file.

6.5 GLI: Generic System Management Logical Interface

6.5.1 Justification for GLI

The GLI addresses the interaction between adjacent hierarchical levels of Generic System
Management functions.

It defines the aspects and protocols necessary to promote interoperability of the GSM entities with one
another.

6.5.2 Justification for GLI Services

The GLI covers the protocols for the actions taken according to RTBP transition definitions between
GSM entities of adjacent management layers. This is necessary for the achievement of interoperability
and consistency between different implementations of GSM.

The protocols for the actions within one GSM entity, i.e. within one management hierarchy level are
left at the designers’ discretion. The GLI covers:

• Configuration / Reconfiguration Management

Control of the configuration of sub-ordinate GSM instances.

NATO UNCLASSIFIED 16
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
• Module Management
The allocation and de-allocation of module resources to integration areas.
• Fault Management
Health monitoring for sub-ordinate GSM instances and escalation of fault handling to
the super-ordinate GSM instance.
• Security Management
Key management between adjacent GSM management layers.

6.6 SMLI: System Management Logical Interface

6.6.1 Justification for SMLI

Application Control involves co-operation between Application Management (AM) in the application
layer and Generic System Management (GSM) in the operating system layer. The term "Application
Management" relates to the part of applications, which manage the Logical Configurations.

The Application Management as well as the Generic System Management consists of a set of
processes. The communication and synchronisation between these specific and generic parts of the
system management, which not necessarily need to be co-located on a PE is performed by the use of
virtual channels. This interface sets forth necessary protocols for the communication between
Application Management and GSM.

6.6.2 Justification for SMLI Services

As the algorithms to handle logical configurations on the higher system management levels and the
algorithms to handle distant errors are of aircraft dependent nature they cannot be handled by the
Generic System Management exclusively.

The SMLI therefore covers:

• Change of Logical Configurations

The change of a logical configuration can be initiated by the application functions or
requested by the generic system management due to a degradation of available core
resources.
• Signalling of Distant Errors
The event of a distant error occurring in a separate integration area may require a
reaction of application management.

6.7 MLI: Operating System Logical Interface

6.7.1 Justification for MLI

The MLI defines the logical interactions between modules so as to meet the module interoperability
requirement. The justification of the Module Logical Interface is defined in reference [9] and reference
[10].

NATO UNCLASSIFIED 17
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)
The MLI provides interoperability between modules. To meet the interoperability requirement the MLI
services as defined in ref. [2] are deemed necessary.

6.7.2 Justification for MLI Services

The MLI services are split into the following groups:

• CFM Resource Management Services

CFM Resource Management Services are needed to provide a way of getting
information on the condition of the CFM such as status reports and test results.
• Download Management Services
The Download Management Services provide the means to transfer software images
and configuration data from the MMM over the network onto the CFM.
• Time Management Services
The time distribution and synchronisation between the CFM’s is catered for by the
Time Management Services.
• Network Management Services
Network Management Services are needed to allow the CFM’s to communicate with
the NSM. The configuration data field has been left unspecified so that it does not
limit the choice of network technology.
• Power Switches Management Services
Power Switches Management Services are to provide the means by which the CFM’s
can communicate with the PCM.

NATO UNCLASSIFIED 18
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

7 Conclusion
The document has justified the contents of the final draft of ASAAC Software Standards for the
aspects of Software Components and Software Interfaces.

The coverage of top-level requirements already listed in section 1.3 is provided by Table 7.

Table 7 – TLR Coverage

Number Components Interfaces

TLR_2 APOS

TLR_3.1 APOS

SMLI

SMOS

SMBP

TLR_3.2 MLI

TLR_3.3 Module Support Layer MOS

SMOS

TLR_3.4 Generic System Management APOS

Runtime Blueprints MOS

SMOS

SMBP

TLR_3.5 Module Support Layer MOS

SMOS

MLI

TLR_8 Operating System OLI

Generic System Management GLI

Module Support Layer MLI

TLR_9 OLI

GLI

SMLI

MLI

NATO UNCLASSIFIED 19
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

Number Components Interfaces

TLR_10 APOS

MOS

SMOS

SMBP

TLR_11 Operating System MOS

TLR_12 APOS

TLR_13.1 OLI

TLR_13.2 APOS

TLR_13.3 SMBP

TLR_13.4 APOS

SMOS

OLI

GLI

TLR_14.1 APOS

MOS

SMBP

TLR_14.2 GLI

TLR_15 Functional Application

Application Management

Runtime Blueprints

TLR_16 Runtime Blueprints SMBP

Generic System Management SMOS

Operating System GLI

TLR_17 Application Management SMOS

Generic System Management SMBP

Runtime Blueprints GLI

SMLI

NATO UNCLASSIFIED 20
 NATO UNCLASSIFIED
Attachment 1 to
STANAG 4626 (Part II)
(Draft 1)

NATO UNCLASSIFIED 21