NORTH ATLANTIC TREATY ORGANIZATION (NATO)read.pudn.com/downloads411/sourcecode/app/1750389/... ·...

NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)

STANAG No. 4626 Part VI Draft 1

NORTH ATLANTIC TREATY ORGANIZATION (NATO)

MILITARY AGENCY FOR STANDARDIZATION (MAS)

STANDARDIZATION AGREEMENT (STANAG)

SUBJECT: MODULAR AND OPEN AVIONICS ARCHITECTURES 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

Promulgated on

NATO UNCLASSIFIED


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

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 VI (Draft 1)

NATO UNCLASSIFIED i


RECORD OF AMENDMENTS

No. Reference/date of amendment

Date entered

Signature

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


RATIFICATION AND IMPLEMENTATION DETAILS STADE DE RATIFICATION ET DE MISE EN APPLICATION

IMPLEMENTATION / MISE EN APPLICATION

INTENDED DATE OF IMPLEMENTATION /

DATE PREVUE POUR MISE EN APPLICATION

DATE IMPLEMENTATION WAS ACHIEVED /

DATE REELLE DE MISE EN APPLICATION

N A T I O N

NATIONAL RATIFICATION REFERENCE DE LA

RATIFICATION NATIONALE

NATIONAL IMPLEMENTING

DOCUMENT / DOCUMENT

NATIONAL DE MISE EN APPLICIATION NAVY

MER ARMY TERRE

AIR NAVY MER

ARMY TERRE

AIR

BE

CA

CZ

DA

FR

GE

HU

IT

LU

NL

NO

PO

SP

TU

UK

US

NATO UNCLASSIFIED iii


RESERVATIONS

RESERVES

NATO UNCLASSIFIED iv


NAVY / ARMY / AIR

NATO STANDARDIZATION AGREEMENT (STANAG)

MODULAR AND OPEN AVIONICS ARCHITECTURE

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

Related Documents:

(a) STANAG 4626 Part I – Architecture

(b) STANAG 4626 Part II – Software

(c) STANAG 4626 Part III – Common Functional Modules

(d) STANAG 4626 Part IV – Packaging

(e) STANAG 4626 Part V – Networks and Communication

NATO UNCLASSIFIED 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


Study n°: Draft n°:I01 Date: 23/11/03 Step n°:

ENGLISH VERSION

ASAAC Phase II

Final Draft of Proposed Guidelines for System Issues Volume 3: System Initialisation and Shutdown

Dernière proposition des directives pour les aspects système – Volume 3: Initialisation et arrêt

du système

Entgültiger Entwurf der Richtlinien für Systemaspekte – Band 3: Systeminitialisierung und

-abschaltung

NATO UNCLASSIFIED


Contents

0 Introduction................................................................................................................................1 0.1 Purpose ......................................................................................................................................1 0.2 Document structure ..................................................................................................................1 1 Scope..........................................................................................................................................3 2 Normative references................................................................................................................4 3 Terms, definitions and abbreviations......................................................................................5 3.1 Terms and Definitions...............................................................................................................5 3.2 Abbreviations.............................................................................................................................5 3.3 Initialisation Shutdown related Terminology .........................................................................6 4 Requirements.............................................................................................................................7 4.1 System Initialisation Requirements.........................................................................................7 4.2 Shutdown Requirements ..........................................................................................................7 5 Concept ......................................................................................................................................8 5.1 System Initialisation..................................................................................................................8 5.1.1 Initialisation of the Initial Configuration..................................................................................8 5.1.2 Subsequent CFM initialisation .................................................................................................9 5.1.3 Initialisation of an Integration Area .......................................................................................11 5.2 System Shutdown ...................................................................................................................11 5.2.1 CFM Shutdown ........................................................................................................................12 5.2.2 Integration Area Shutdown ....................................................................................................12 5.2.3 Final Configuration Shutdown...............................................................................................13 5.3 Supporting concepts...............................................................................................................13 5.3.1 CFM States ...............................................................................................................................13 5.3.2 Multi IMA Rack initialisation...................................................................................................14 5.3.3 System Time initialisation ......................................................................................................14 5.3.4 Network and NSM initialisation..............................................................................................14 6 Guidelines for System Initialisation and Shutdown ............................................................16 6.1 Initialisation guidelines...........................................................................................................16 6.2 Shutdown guidelines ..............................................................................................................16 Annex A (Informative) System Initialisation scenarios ...................................................................17 Annex B (Informative) IA Initialisation sequence example .............................................................24

NATO UNCLASSIFIED 2


List of Figures Figure 1 - ASAAC Standard Documentation Hierarchy................................................................... 1 Figure 2 - Document Structure........................................................................................................... 2 Figure 3 - Initial Configuration – System management hierarchy.................................................. 9 Figure 4 - ASAAC Core Initialisation Sequence ............................................................................... 9 Figure 5 - Subsequent CFM initialisation – System management hierarchy ..............................10 Figure 6 - Principle for local control of an MMM FS ......................................................................10 Figure 7 - Principle for Remote control of an MMM FS .................................................................11 Figure 8 - IA Configuration – System management hierarchy......................................................11 Figure 9 - CFM Shutdown – System management hierarchy........................................................12 Figure 10 - IA Shutdown – System management hierarchy..........................................................13 Figure 11 - Principle for Multi-Rack system - Initial configuration...............................................14 Figure A. 1 - Initialisation sequence to Initial Configuration ........................................................18 Figure A. 2 - Subsequent CFM initialisation (FS located on the AC MMM) .................................19 Figure A. 3 - Subsequent CFM initialisation (Remote Access).....................................................19 Figure A. 4 - Initialisation of an Integration Area ...........................................................................20 Figure A. 5 - CFM shutdown.............................................................................................................21 Figure A. 6 - CFM power off..............................................................................................................21 Figure A. 7 - Shutdown of an Integration Area...............................................................................22 Figure A. 8 - Shutdown of the Initial Configuration .......................................................................23 Figure B. 1 - Baseline configuration 4 (config_id = 400) ...............................................................24 Figure B. 2 - Baseline configuration 1 (Config_id = 100)...............................................................26 Figure B. 3 - Intermediate States (Config_id = 140) ......................................................................26 Figure B. 4 - Intermediate States (Config_id = 141) ......................................................................27

List of Tables Table B. 1 - Core Platform system states and Config_id to reach the Baseline

Configuration 4...........................................................................................................................25

NATO UNCLASSIFIED 3


1 Introduction

1.1 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 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:

- Standards that describe the architecture overview to all interfaces required to implement the core within avionics system, using a top down approach,

- Guidelines for system implementation through application of the standards.

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

Guidelines for System Issues • System Management • Fault Management • Initialisation / Shutdown • Configuration / Reconfiguration • Time Management • Security • Safety

Standard for Architecture

Standard for Common Functional Modules

Standard for Communications and Network

Standard for Packaging

Standard for Software

Figure 1 - ASAAC Standard Documentation Hierarchy

1.2 Document structure

The document contains the following sections:

Section 2, Scope of the document

NATO UNCLASSIFIED 1


Section 3, Normative references

Section 4, The terms, definitions and abbreviations,

Section 5, Requirements for Initialisation and shutdown of an IMA system,

Section 6, Concept for Initialisation and shutdown of an IMA system,

Section 7, Guidelines for Initialisation and shutdown of an IMA system.

In addition, the following annexes are provided:

Annex A System Initialisation scenarios,

Annex B IA Initialisation Sequence example.

ScopeScope

Section 1

Normative ReferencesNormative References

Section 2

Terms & DefinitionsTerms & Definitions

Section 3

Initialisation & ShutdownRequirements

Initialisation & ShutdownRequirements

Section 4

Initialisation &Shutdown Concept

Initialisation &Shutdown Concept

Section 5

InitialisationConcept

InitialisationConcept

ShutdownConcept

ShutdownConcept

SupportingConcepts

SupportingConcepts

Initialisation &Shutdown Guidelines

Initialisation &Shutdown Guidelines

Section 6

InitialisationGuidelines

InitialisationGuidelines

ShutdownGuidelines

ShutdownGuidelines

Volume 3System Initialisation &

Shutdown

Volume 3System Initialisation &

Shutdown

Proposed Guidelinesfor System Issues

InitialisationRequirements

InitialisationRequirements

ShutdownRequirements

ShutdownRequirements

Figure 2 - Document Structure

NATO UNCLASSIFIED 2


2 Scope

The ASAAC concepts and ASAAC standards mandate the functionality and in some cases the implementation of that functionality that a system must adopt in order for it to be considered 'ASAAC compliant'. However, in addition to these standards and concepts, the ASAAC Programme has also defined a series of guidelines which although not mandated are offered in order to support the ASAAC system integrator in defining and building a system. These guidelines represent the findings of the ASAAC Team during the validation phase of the Programme during which representative systems were designed and implemented in order to validate the standards and concepts.

This document (7 volumes) provides System Issues guidelines supplementary to the Architecture Standard.

This volume is the third of the seven volumes of Final Draft of Guidelines for System Issues, which have been introduced within the Architecture Standard:

- It gives the initialisation and shutdown concept applicable to an IMA (ASAAC) avionic system for aerospace applications in section 6.

- It gives guidance for implementation of system initialisation and shutdown for an IMA (ASAAC) avionic system for aerospace applications in section 7.

NATO UNCLASSIFIED 3


3 Normative references

A) References to published standards None. B) References to standards in preparation 1. Final Draft of Proposed Standards for Architecture

Document ref.: ASAAC2-STA-32460-001-CPG

2. Final Draft of Proposed Standards for Software Document ref.: ASAAC2-STA-32410-001-SWG

3. Final Draft of Proposed Standards for Network Document ref.: ASAAC2-STA-32420-001-HWG

4. Final Draft of proposed standards for Common Functional Module Document ref.: ASAAC2-STA-32430-001-HWG

5. Final Draft of Proposed Standards for Packaging Document ref.: ASAAC2-STA-32440-001-HWG

6. Final Guidelines for System and Fault Management – Volumes 1 to 7 Document ref.: ASAAC2-GUI-32450-001-CPG

C) References to other documents None. D) References to documents from other organisations (selected US standards as stated above) None.

NATO UNCLASSIFIED 4


4 Terms, definitions and abbreviations

4.1 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 such recommendations or advice are 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.

4.2 Abbreviations

AC Aircraft ALT Absolute Local Time AM Application Manager CFM Common Functional Module CPP Core Processing Platform DPM Data Processing Module FS File Server GLI GSM logical Interface GPM Graphic Processing Module GSM Generic System Management IA Integration Area IMA Integrated Modular Avionics LRC Line Replaceable Chamber MLI Module Logical Interface MMM Mass Memory Module MSL Module Support Layer NSM Network Support Module OS Operating System OSL Operating System Layer PBIT Power-up Built In Test PCM Power Conversion Module PSN Packet Switched Network RE Resource Element RTBP Run Time Blue Prints RTOS Real Time Operating System SMLI System Management Logical Interface SMOS System Management to Operating System interface SPM Signal Processing Module TC Transfer Channel TLS Three Layer Stack

NATO UNCLASSIFIED 5


VC Virtual Channel

4.3 Initialisation Shutdown related Terminology

System initialisation defines the activity from power on to a state of operational readiness.

Operational Readiness is defined as the state reached immediately prior to the downloading and instantiating of functional applications. At this point:

• All CFMs to be used in the first operational configuration (including hot and warm spares) are powered up and loaded with their respective MSL and OSL,

• A GSM hierarchy (Integration Area definition) has been instantiated,

• A Time hierarchy has been instantiated.

Operational Configuration is defined as a state where functional applications are running.

System Shutdown is achieved through a series of system reconfigurations, reducing system functionality until the point when power can be removed.

NATO UNCLASSIFIED 6


5 Requirements

Volume 1 of this document defines System Management as being responsible for managing the system immediately after power is applied to the system, through to system shutdown and power off.

The downloading and instantiating of functional applications is described as system configuration and is covered in volume 4 of this document.

5.1 System Initialisation Requirements

• The system shall have a minimum power requirement at initialisation.

• System management shall be responsible for performing a controlled system initialisation.

• The information required for a controlled system initialisation shall be contained in the blueprints.

• System status shall be available when initialisation is in progress, and when completed.

This last point means that a release decision can be made subsequently on the status of the overall system (and the status of its subsystems) for instance, that the full system is available, or that there are partial failures.

5.2 Shutdown Requirements

• System management shall be responsible for performing a controlled system shutdown.

• Information required for a controlled shutdown procedure shall be contained in run-time blueprints.

• It shall be possible to store ‘essential’ data during the shutdown procedure. This data may include, but is not limited to:

• Information on system states and modes before shutdown,

• Fault Management data for test and maintenance,

• Essential constants and variables.

• For some applications, data information shall be stored for short time outages. Examples are:

• Radar and / or Electro-Optic track files,

• Electronic Warfare threat libraries.

• Provision shall be made for all volatile memories holding classified data to be appropriately erased before power loss in the system.

NATO UNCLASSIFIED 7


6 Concept

6.1 System Initialisation

The System Initialisation concept consists of a number of stages:

• Boot and initialisation of a minimal set of CFMs: Initialisation Cluster.

Initialisation Cluster is defined as a core set of CFMs necessary to implement and manage the power-up and instantiation of the remainder of the core processing system.

• Boot and initialisation of further sets of Initialisation Clusters to provide fault tolerance where required.

• Instantiation of a GSM hierarchy on the initialisation cluster.

• Power-up and instantiation of the core processing system prior to the instantiation of functional applications.

• Instantiation of a GSM hierarchy on the core processing system.

• The CFM that provides the Time Master Reference Clock instantiates a Time hierarchy.

The System Initialisation concept consists of three mechanisms, which are then described, in more detail:

• Initialisation of the Initial Configuration (6.1.1),

• Subsequent CFM initialisation (6.1.2),

• Initialisation of an Integration Area (6.1.3).

The aim of these mechanisms is to reach a basic configuration which can then be used to support the loading and subsequent running of an entire system configuration. These further steps use the Configuration/Reconfiguration mechanisms as described in Volume 4.

6.1.1 Initialisation of the Initial Configuration The concept for the minimum set of modules (Initialisation Cluster) required for the Initial configuration is:

• PCM, which powers the Initialisation Cluster by default. Note that the power management concept has two PCMs. However, for ease of reading this document, only one PCM will be referred to.

• MMM containing the RTBP and software images for the Initial configuration.

• NSM with default connections to the MMM and PCM.

The mechanism for the Initial Configuration Initialisation covers the events/interactions that take the system from a non-powered state to the Initial Configuration state where the three CFMs are initialised (see section 6.3 for individual CFM initialisation). At this point the MMM launches the initial AC-GSM and its associated AM (see Figure 3). Then it can communicate with the PCM in order to progress the system initialisation to subsequent CFMs as shown in Figure 4.

The RE-GSM is responsible for the IA-GSM, AC-GSM and AM creation locally and starts it by using the process creation service from an action list associated to a Configuration.

NATO UNCLASSIFIED 8


RE-GSM

RE-GSMMMM

PCM

AM FS

NSM

AC-GSM

Figure 3 - Initial Configuration – System management hierarchy

SystemPower

Applied

PCM MMM

Power Applied to NSM

NSM

PCMPBIT

PCMPBIT

MMMPBIT

MMMPBIT

MMM MSL bootfunction instantiates

TLS and RE-GSM

MMM MSL bootfunction instantiates

TLS and RE-GSM

NSMPBIT

NSMPBIT

NSM Usesdefaultconfig.

NSM Usesdefaultconfig.

Power Applied to MMM

PCM Reports PBIT Status

NSM Reports PBIT Status

MMM downloads OSL to PCM MMM download configtable to NSM

PCM MSL bootfunction instantiates

TLS and RE level GSM

PCM MSL bootfunction instantiates

TLS and RE level GSM

Health message betweenAC and RE GSMs Initialisation

ClusterInitialised

InitialisationCluster

Initialised

RE Level GSMinstantiates AC-GSM

RE Level GSMinstantiates AC-GSM

Figure 4 - ASAAC Core Initialisation Sequence

6.1.2 Subsequent CFM initialisation This Subsequent CFM initialisation phase extends the system initialisation with the powering up and the initialisation of all the necessary CFMs (see section 6.3) belonging to a system hierarchy tree of an Integrated Area or of an Aircraft level System Management. An example is shown in Figure 5 with an AC-GSM.

NATO UNCLASSIFIED 9


RE-GSM

RE-GSMMMM

PCM

AM FS

DPM

AC-GSM

RE-GSM

NSM

Figure 5 - Subsequent CFM initialisation – System management hierarchy

Two cases can be distinguished:

The File Server (FS) is located on the Aircraft level MMM for the Initial configuration,

The FS is located on a remote MMM (see section 6.1.2.2).

6.1.2.1 OSL and RTBP image download from local MMM The AC (or IA) GSM asks its local FS for the necessary information to initialise a subsequent CFM that belongs to its Integrated Area hierarchy (inc. AC). The communication sequence is shown in Figure 6.

CFM

MMMA/C

5: Download SW Image

PCM

1: set Power to new CFM

2: Power on

3: set up comms channel (TC)

4a: get PBIT4b: send PBIT

FS

Figure 6 - Principle for local control of an MMM FS

6.1.2.2 OSL and RTBP image download from remote MMM An IA GSM (or AC GSM) shall be able to control the FS located on a remote MMM to initialise a subsequent CFM that belongs to its Integrated Area hierarchy (inc. AC).

A specific request message (5 on Figure 7) sent to the FS containing the necessary instructions for activating the download messages for OSL and RTBP. This instruction contains the information by which the image is to be sent and acknowledged that goes back to the IA CFM.

NATO UNCLASSIFIED 10


MMM

CFM

FS

DPMI/A

6: Download SW Image

PCM

1: set Power to new CFM

2: Power on

3: set up TC to MMM (FS access)

4a: get PBIT4b: send PBIT

5: Request Download SW Image

Figure 7 - Principle for Remote control of an MMM FS

6.1.3 Initialisation of an Integration Area The mechanism for the initialisation of an Integration Area changes a former system configuration by introducing new Integration Area hierarchy level. This applies directly to the Initial Configuration for the creation of the very first Integration Area hierarchy below the Aircraft level CFM or within an existing system hierarchy of IA with the addition of a new level. This sequence includes the creation of the necessary IA level GSM and the configuration of the hierarchy links. It is supported by the previous sequence Subsequent CFM Initialisation. The AC-GSM (or IA-GSM) instructs a subordinate RE-GSM to create an IA-GSM and then, as part of the configuration process, the GLI links between the different levels of GSM hierarchy are put in place. An example is shown in Figure 8 where the new integration area has a DPM and an SPM.

RE-GSM

RE-GSMMMM

PCM

AM FS

DPM

AC-GSM

RE-GSM

SPM

IA-GSM

NSM

RE-GSM

Figure 8 - IA Configuration – System management hierarchy

6.2 System Shutdown

Assumption: Functional Applications have been stopped using the Configuration/Reconfiguration mechanisms as described in Volume 4.

Complete shutdown uses through three mechanisms: Integration Area Shutdown, CFM Shutdown and finally Final Configuration Shutdown: -

• CFM Shutdown covers the controlled shutdown of a RE level CFM up to the power down of the CFM.



• Integration Area Shutdown deals with the controlled shutdown of an Integration Area GSM hierarchy.

• Final Configuration Shutdown deals with the shutdown of the MMM (Aircraft level), PCM and the NSM.

6.2.1 CFM Shutdown This mechanism supports the other shutdown aspects: Integration Area Shutdown and Final Configuration Shutdown. Basically, the CFM shutdown procedure halts all the processes running on the CFM. At the end of this step only the RE GSM is running.

After the CFM shutdown sequence, the CFM power down procedure controlled by the AC or IA level CFM can be applied. This instructs the PCM to remove power from the CFM. An example is shown in Figure 9.

RE-GSM

RE-GSMMMM

PCM

AM FS

DPM

AC-GSM

RE-GSM

SPM

IA-GSM

NSM

RE-GSM

Figure 9 - CFM Shutdown – System management hierarchy

6.2.2 Integration Area Shutdown The Integration Area Shutdown mechanism shuts down the CFMs belonging to the integration area (CFM Shutdown) and applies a change of configuration allowing communications between the parent GSM (AC or IA level) and the subordinate RE-GSM hosted on the same PE as the IA-GSM.

The ordering of the process shutdown is pre-determined (at design time) according to the GSM hierarchy configuration that is currently running. Then the parent GSM manages the CFM shutdown ordering. An example is shown in Figure 10. This procedure can be repeated until only the Initial Configuration is left.



RE-GSM

RE-GSMMMM

PCM

AM FS

DPM

AC-GSM

RE-GSM

SPM

IA-GSM

NSM

VC/TC Added

Figure 10 - IA Shutdown – System management hierarchy

6.2.3 Final Configuration Shutdown The Final Configuration Shutdown mechanism shuts down the remaining CFMs that belong to an Initial Configuration. At this point, only the PCMs and the default connected CFM are powered on. The system is in a state where power can be removed from the PCMs or the system re-started.

6.3 Supporting concepts

6.3.1 CFM States From the system point of view, three states can characterise a CFM:

• CFM Booted,

• CFM Initialised,

• CFM Operational.

6.3.1.1 CFM Booted The CFM booted status is when the hardware components are successfully powered up, the boot sequence performed including PBIT and the resident MSL started.

In this state, the CFM shall be able to reply to a Module Logical Interface (MLI) command. The CFM shall provide a single default TC to enable this communication.

6.3.1.2 CFM Initialised From CFM booted, it shall be able to process the MLI commands required for the CFM initialisation. This set of commands shall bring the CFM into its Initialisation status where the OSL image and RTBP are downloaded and the OS, RE-GSM started.

In the CFM Initialised state, the CFM can respond to another GSM request based on GSM Logical Interface (GLI) commands. This is at “Operational Readiness” and ready to receive functional applications.

6.3.1.3 CFM Operational The CFM Operational state is when the CFM has received the functional applications and they are running (out of scope for Initialisation).



6.3.2 Multi IMA Rack initialisation In the case where multi-rack Initial Configuration is required, the minimum set of modules (initialisation cluster) includes the PCM(s) and, possibly, the NSM(s) from the additional racks. In each of these additional racks, the PCM shall power at least the NSM by default. Then the AC level MMM monitors the further steps of the system initialisation (see Figure 11).

MMMPCM NSM

PCM NSM

PCM NSM

Power

Rack A

Rack B

Rack C

Figure 11 - Principle for Multi-Rack system - Initial configuration

Aircraft Power shall be supplied to a Line Replaceable Chamber (see Packaging Standard reference 5) in each rack. The ASAAC network connections between CFM from two racks can be done via:

• Interconnection of back-planes,

• Interconnection of NSM.

6.3.3 System Time initialisation During the Initial Configuration or later, the Absolute Local Time (ALT) initialisation and synchronisation shall be carried out on the Initialisation Cluster. Then, for every subsequent CFM initialisation, these two procedures have to be performed as well. They shall be started after the PBIT has been received and after the RE-GSM has configured the time management processes with clock parameters provided by the RTBP. This has to be completed before applications, dependent on system time, start.

Volume 5 of this document provides more details about Time Management on a Core Processing Platform.

6.3.4 Network and NSM initialisation There are two aspects to the initialisation of the ASSAC network. The first deals with the configuration of the default TC on a CFM prior to the loading to of the RTBP and the initialisation of its GSM. This has been covered by the CFM Initialisation in section 6.3.1.2. The second deals with the configuration of network paths by the NSM.

The NSM is pre-configured (i.e. default network routing table) such that it can provide a network connection to the Initial Cluster. Following the application of power to the NSM, it performs its CFM Boot, PBIT and applies the default configuration.

When an updated configuration is required, a GSM (AC or IA level) sends a new configuration command to the NSM to provide a network connection between the necessary CFMs. The NSM then applies this new configuration (i.e. updated network routing table). Refer also to the System



Management Guidelines Volume 1 of this document, which presents the network management principle within a Core system



7 Guidelines for System Initialisation and Shutdown

7.1 Initialisation guidelines

GUI-IS_1: The system designer should consider the system power required for every configuration.

GUI-IS_2: It is recommended that the AC-GSM is located on the MMM.

GUI-IS_3: The system designer should ensure that the NSM and PCM have a default configuration that supports the Initialisation Cluster. This allows subsequent reconfiguration of the switches by the RTBP.

GUI-IS_4: It is recommended that System Initialisation needs to be time-bound, as defined by the project.

7.2 Shutdown guidelines

GUI-IS_5: The ordering of the process shutdown should be determined during the design time phase according to the GSM hierarchy configuration that was currently running.

GUI-IS_6: The shutdown of an IMA system should start by reconfiguration sequences with the objective to stop processes and communications in a whole branch of the GSM hierarchy.

GUI-IS_7: Before starting a Shutdown process, it is recommended to designate an MMM as an AC level to be able to log all events during the whole process.

GUI-IS_8: During the Shutdown sequences, it is recommended to manage the Time Management hierarchy.



Annex A (Informative)

System Initialisation scenarios

A.1. Foreword

This Annex provides a system level description for the Initialisation sequences. It is not an ASAAC Standard. It is given here for information only, showing an example of how intra-GSM communications may be implemented.

The initialisation is described through three phases: -

• Initial Configuration Initialisation covers the initialisation from power on of the MMM, PCM and NSM to form the Initial Configuration. This includes the formation of a RE GSM on the MMM and the PCM and the AC GSM on the MMM.

• Subsequent CFM Initialisation deals with the addition of CFM(s) belonging to a system management hierarchy (both Integration Area and Aircraft hierarchies) with the initialisation of an RE level GSM,

• Initialisation of an Integration Area after the formation of the Initial Configuration or Subsequent CFM Initialisation. This deals with the build up of a new hierarchy or the reconfiguration of an existing system hierarchy of CFMs.

Note: Before the RE-GSM is running on a given CFM, all communication uses the MLI. Once the RE-GSM is running, then the GSM uses SMOS, and GLI communications. Once an Application Manager is involved, the communications with it use SMLI. For further details on the precise mechanisms of these services, refer to the Software Standards [2].

A.2. Initialisation of the Initial Configuration

Figure A. 1 shows a sequence diagram, which includes example MLI messages between each of the CFMs in the Initial Cluster. This format is used for each subsequent scenario.



Figure A. 1 - Initialisation sequence to Initial Configuration

A.1.1 Subsequent CFM initialisation

The two cases described in 6.1.2 are depicted separately through the following sequence diagrams:

• The File Server (FS) is located on the Aircraft level MMM for the Initial configuration,

• The FS is located on a remote MMM (see section 6.1.2.2).



Figure A. 2 - Subsequent CFM initialisation (FS located on the AC MMM)

Figure A. 3 - Subsequent CFM initialisation (Remote Access)



A.1.2 Initialisation of an Integration Area

This sequence includes the creation of the necessary IA level GSM and the configuration of the hierarchy links. It is supported by the previous sequence Subsequent CFM Initialisation.

Figure A. 4 - Initialisation of an Integration Area

A.3. Core Processing System Shutdown scenarios

The shutdown is also described through three phases, Integration Area Shutdown, CFM Shutdown and finally Final Configuration Shutdown: -

Integration Area Shutdown deals with the controlled shutdown of an Integration Area GSM hierarchy. This step uses the following step CFM Shutdown.

CFM Shutdown covers the controlled shutdown of a RE level CFM up to the power down of the CFM.

Final Configuration Shutdown deals with the shutdown of the MMM (Aircraft level), PCM and the NSM.



A.1.3 CFM Shutdown and power down

Figure A. 5 - CFM shutdown

Figure A. 6 - CFM power off



A.1.4 Shutdown of an Integration Area

Figure A. 7 - Shutdown of an Integration Area



A.1.5 Shutdown of the Initial Configuration

Figure A. 8 - Shutdown of the Initial Configuration



Annex B (Informative)

IA Initialisation sequence example

B.1. Foreword

This annex covers the initialisation of a Core platform to reach a GSM hierarchy covered by an IA configuration. This is called the Baseline Configuration 4 (IA level config_id = 400). It is not an ASAAC Standard. It is given here for information only, showing an example of how the initialisation sequence may be implemented.

B.2. Sequence

The example Core Processing Platform (CPP) consists of two SPM, two DPM, one MMM, one GPM and one NSM. All CFM except the NSM have a Three-Layer Stack. There is no PCM, therefore every CFM boots and initialised when power is applied.

In this configuration, the GSM hierarchy is depicted in the Figure B. 1 with an AC-GSM (GSM_id = 99) onto the MMM, an IA-GSM (GSM_id = 96) onto the DPM2 and a RE-GSM (GSM_id = 89 down to 84) on each of the six CFMs of the CPP. This system management hierarchy, called Baseline Configuration 4 (config_id = 400), is the running state for the necessary GSM instances with the CPP.

RE-GSM

RE-GSM

RE-GSM

-MMM

DPM1

SPM1

AM FS

RE-GSMDPM2

RE-GSM SPM2

IA-GSMAM

Id= 8 6Id=

8 9Id=

8 4Id=

RE-GSM GPM

8 7Id=

8 5Id=

8 8Id=

9 6Id=

AC-GSM

9 9

Figure B. 1 - Baseline configuration 4 (config_id = 400)

Several intermediate steps to reach the Baseline Configuration 4 (IA level config_id = 400) are required according to the GSM functionality and the core platform capabilities.

These steps to reach the Baseline Configuration 4 are identified in Error! Reference source not found. and intermediate GSM hierarchy illustrated in Figure B. 2, Figure B. 3 and Figure B. 4.



System mgt hierarchy Action on involved GSMs Configuration Steps - Description ChangeConf on Level Identifier Identifier

1 – CFM initialisation The RE-GSM is initialised and waiting for a configuration change (GLI). The GLI VC to the AC-GSM are defined and attached.

Internal to all CFM

RE-GSM GSM_id = 84 to 89

RE Config_id = 0

2 – AC GSM creation The RE-GSM is asked to change configuration to create the AC-GSM. The GLI VC to the local RE-GSM are defined and attached to the AC-GSM.

MMM RE-GSM GSM_id = 86 RE Config_id = 1

3a – Baseline configuration_1 creation The AC-GSM is asked to change configuration to create and attach the GLI VC to the remote RE-GSM.

MMM AC-GSM GSM_id = 99 IA Config_id = 100

3b – Baseline configuration_1 creation: RE level configuration The RE-GSM is asked to load the RE configuration subordinated to the AC hierarchy of the Baseline configuration.

MMM DPM1 DPM2 SPM1 SPM2 GPM

RE-GSM GSM_id = 84 to 89

RE Config_id = 10000

4a – IA GSM creation The AC-GSM is asked to change configuration to create the IA-GSM. The AC-GSM sends GLI configuration changes to the remote DPM2 RE-GSM.

MMM AC-GSM GSM_id=99 IA Config_id = 140

4b – IA GSM creation The RE-GSM is asked to change configuration to create the IA-GSM. The GLI VC between the local RE-GSM and IA-GSMs are defined and attached. On the IA-GSM, the GLI VC to the AC-GSM are defined and attached.

DPM2 RE-GSM GSM_id = 88 RE Config_id = 14000

5a – AC-RE GLI VC creation The AC-GSM is asked to change configuration to create the GLI VC for the new hierarchy.


5b – AC-RE GLI VC creation The RE-GSMs (under the new IA-GSM hierarchy) are asked to change configuration to create the GLI VC to the new IA-GSMs.

DPM2 SPM1 SPM2

RE-GSM GSM_id = 88 GSM_id = 85 GSM_id = 84


6a - Baseline configuration_4 creation: AC-IA GLI link attachment The AC-GSM is asked to change configuration to attach the GLI VC to the new IA-GSMs and remove the GLI VC to the RE-GSM.


6b – Baseline configuration_4 creation: RE level configuration The RE-GSM is asked to load the RE configuration subordinated to the AC hierarchy of the Baseline configuration.

MMM DPM1 GPM

RE-GSM GSM_id = 86, 87 and 89


6c - Baseline configuration_4 creation: IA-RE GLI link attachment The IA-GSM is asked to change configuration to create and attach the GLI VC to the RE-GSM under its hierarchy and remove the GLI VC to the former AC-GSM.

DPM2 IA-GSM GSM_id = 96 IA Config_id = 400

6d – Baseline configuration_4 creation: RE level configuration The RE-GSM is asked to load the RE configuration subordinated to the IA hierarchy of the Baseline configuration.

DPM2 SPM1 SPM2

RE-GSM GSM_id = 84, 85 and 88


Table B. 1 - Core Platform system states and Config_id to reach the Baseline Configuration 4

The reached final Integration Area level configuration (Config_id = 400) was shown in Figure B. 1. The intermediate states are shown in the three diagrams below for the Integration Area level configurations config_id = 100, config_id = 140, config_id = 141.



RE-GSM

RE-GSM

RE-GSM

RE-GSMMMM

DPM1

SPM1

GPM

AM FS

RE-GSMDPM2

RE-GSM SPM2

AC-GSM

9 9Id= 8 6Id=

8 9Id=

8 4Id=

8 7Id=

8 5Id=

8 8Id=

Figure B. 2 - Baseline configuration 1 (Config_id = 100)

RE-GSM

RE-GSM

RE-GSM

RE-GSMMMM

DPM1

AM FS

RE-GSM

RE-GSM

8 6Id=

8 9Id=

SPM2

8 4Id=

GPM

8 7Id=

SPM1

8 5Id=

DPM2

8 8Id=

IA-GSM9 6Id=

AC-GSM

9 9Id=

Figure B. 3 - Intermediate States (Config_id = 140)



RE-GSM

RE-GSM

RE-GSMMMM

DPM1

AM FS

RE-GSM

8 6Id=

8 9Id=

AC-GSM

9 9Id=

RE-GSM

RE-GSM SPM1

DPM2

SPM2

8 5Id=

8 8Id=

8 4Id=

GPM

8 7Id=

IA-GSM9 6Id=

Figure B. 4 - Intermediate States (Config_id = 141)



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

ENGLISH VERSION

ASAAC Phase II

Final Draft of proposed Guidelines for System Issues Volume 4: System Configuration/Reconfiguration

Dernière proposition des directives pour les aspects système – Volume 4: Configuration de

système

Endgültiger Entwurf der Richtlinien für Systemaspekte – Band 4: Systemkonfiguration

NATO UNCLASSIFIED


Contents

0 Introduction............................................................................................................................. 1 0.1 Purpose ................................................................................................................................... 1 0.2 Document Structure............................................................................................................... 2 1 Scope....................................................................................................................................... 3 2 Normative References............................................................................................................ 4 3 Terms, Definitions and Abbreviations.................................................................................. 5 3.1 Terms and Definitions............................................................................................................ 5 3.2 Abbreviations.......................................................................................................................... 5 4 Configuration/Reconfiguration Requirements .................................................................... 7 5 Concept ................................................................................................................................... 8 5.1 Configurations ........................................................................................................................ 8 5.1.1 Logical Configuration ............................................................................................................ 8 5.1.2 Physical Configuration .......................................................................................................... 8 5.1.3 Summary for Configuration Definitions............................................................................... 8 5.2 System States, Modes and Configurations ......................................................................... 8 5.2.1 Resource Element Configuration ......................................................................................... 9 5.2.2 Integration Area Configuration ............................................................................................. 9 5.2.3 States and Transitions........................................................................................................... 9 5.2.4 States of a compound Object during Reconfiguration.....................................................10 5.3 Reconfiguration ....................................................................................................................11 5.4 Configuration/Reconfiguration Mechanisms and System Management ........................11 5.4.1 System Management Hierarchy..........................................................................................11 5.4.2 Resource Allocation and Identification of the Configurations ........................................13 5.4.3 Configuration for shared Resources..................................................................................14 5.4.4 Use of Spares for a new Configuration..............................................................................15 5.5 Configuration/Reconfiguration GLI Commands ...............................................................15 5.5.1 GLI Commands .....................................................................................................................15 5.5.2 Actions ..................................................................................................................................15 5.5.3 GLI Commands Action List .................................................................................................16 5.6 Configurations managed within the GSM..........................................................................17 6 Configuration/Reconfiguration Guidelines........................................................................19 6.1 System Behaviour and Configurations..............................................................................19 6.2 Configurations/Reconfigurations and the GSM Hierarchy ..............................................19 6.3 Configurations for Spare and shared Resources .............................................................20 6.4 System Design Process.......................................................................................................20 Annex A (Informative) Example of the Use of a Reconfiguration after a CFM Failure..............21 Annex B (Informative) Examples for Configuration/Reconfiguration Sequences.....................25

NATO UNCLASSIFIED 1


List of Figures Figure 1 – ASAAC Standard Documentation Hierarchy .................................................................. 1 Figure 2 – Document Structure.......................................................................................................... 2 Figure 3 – Re/configuration function and interfaces ....................................................................... 7 Figure 4 – Configuration of an IA as a composite of several RE.................................................... 9 Figure 5 – Generic State Transition of a component.....................................................................10 Figure 6 – State Transitions of GSM components of an IA with 3 RE .........................................11 Figure 7 – Example of the Functional Partitioning ........................................................................12 Figure 8 – Proposal for Resource allocation and GSM hierarchy................................................14 Figure 9 – Alternative proposal for Resource allocation and GSM hierarchy ............................14 Figure 10 – Local RTBP actions grouped by activities .................................................................16 Figure A.1 – Example System prior to Action Configuration Change .........................................21 Figure A.2 – Logical Model of Integration Area IA1 .......................................................................21 Figure A.3 – Resource Allocation of the Example .........................................................................22 Figure A.4 – Example System after the Reconfiguration Process ...............................................22 Figure A.5 – System Reconfiguration with strong sequential Action Sequences......................23 Figure A.6 – Reconfiguration with several parallel Atomic Actions ............................................24 Figure B.1 – Generic Sequence for Synchronised Change of Subordinate Configurations .....27 Figure B.2 – Generic Sequence to stop a RE configuration .........................................................28 Figure B.3 – Load RE Configuration................................................................................................28 Figure B.4 – Run RE Configuration .................................................................................................29 Figure B.5 – Restart Process ...........................................................................................................29 Figure B.6 – Stop IA Configuration..................................................................................................30 Figure B.7 – Load IA Configuration .................................................................................................31 Figure B.8 – Run IA Configuration...................................................................................................31 Figure B.9 – Change of IA Configuration ........................................................................................32 Figure B.10 – Fault-Driven Change of IA Configuration................................................................33 Figure B.11 – AM-Driven Change of IA Configuration...................................................................34

NATO UNCLASSIFIED 2


1 Introduction

1.1 Purpose


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:














Figure 12 – ASAAC Standard Documentation Hierarchy

NATO UNCLASSIFIED 1


1.2 Document Structure


Section 2, Scope,

Section 3, Normative References,

Section 4, Terms, Definitions and Abbreviations,

Section 5, Configuration/Reconfiguration Requirements,

Section 6, Concept,

Section 7, Configuration/Reconfiguration Guidelines.

In addition the following annexes are provided:

Annex A gives an example of the use of a reconfiguration after a CFM Failure,

Annex B, gives an example for Configuration/Reconfiguration sequences.

ScopeScope

Section 1


Section 2


Section 3

Configuration /ReconfigurationRequirements

Configuration /ReconfigurationRequirements

Section 4

Configuration /Reconfiguration

Concept


Concept

Section 5

Definition forConfiguration

ReconfigurationStates & Modes

Definition forConfiguration

ReconfigurationStates & Modes

Links withSystem

Management

Links withSystem

Management

GSM logicalinterface

GSM logicalinterface

GSMconfiguration

GSMconfiguration


Guidelines


Guidelines

Section 6

Systembehaviour

Systembehaviour

GSMhierarchy

GSMhierarchy

Management ofSpares/Shared

Management ofSpares/Shared

SystemDesign

SystemDesign

Volume 4Configuration /Reconfiguration

Volume 4Configuration /Reconfiguration

Proposed Guidelinesfor System Issues

Figure 13 – Document Structure

NATO UNCLASSIFIED 2


2 Scope

The ASAAC concepts and ASAAC standards mandate the functionality and in some cases the implementation of that functionality that a system must adopt in order for it to be considered 'ASAAC compliant'. However, in addition to these standards and concepts, the ASAAC Programme has also defined a series of guidelines that although not mandated are offered in order to support the ASAAC system integrator in defining and building a system. These guidelines represent the findings of the ASAAC Team during the validation phase of the Programme during which representative systems were designed and implemented in order to validate the standards and concepts.


This volume is the fourth of the seven volumes of Final Draft of Guidelines for System Issues, which have been introduced within the Architecture Standard:

- It gives the Configuration/Reconfiguration concept applicable to an IMA (ASAAC) avionic system for aerospace applications in section 6.

- It gives guidance for implementation of Configuration/Reconfiguration management for an IMA (ASAAC) avionic system for aerospace applications in section 7.

NATO UNCLASSIFIED 3


3 Normative References

A) References to published standards

None.

B) References to standards in preparation

1. Final Draft of Proposed Standards for Architecture Document ref.: ASAAC2-STA-32460-001-CPG






C) References to other documents

None.

D) References to documents from other organisations (selected US standards as stated above)

None.

NATO UNCLASSIFIED 4


4 Terms, Definitions and Abbreviations






4.2 Abbreviations

AC Aircraft

AM Application Management

ASAAC Allied Standard Avionics Architecture Council

BIT Built in Test

BMC Between Module Communications

CFM Common Functional Module

CM Configuration Manager

FA Functional Application

FM Fault Manager

GLI GSM Logical Interface

GSM Generic System Manager

IA Integration Area

IMA Integrated Modular Avionics

IMC Intra Module Communications

IPC Intra Processor Communications

IPEC Intra Processing Element Communications

MC Module Clock

NSM Network Support Module

OS Operating System

OSL Operating System Layer

PBIT Power up/Power down Built in Test

PCM Power Conditioning Module

PE Processing Element

RE Resource Element

REP RE Processor

RTBP Run-Time Blueprint

SM System Management

SMLI System Manager Logical Interface

NATO UNCLASSIFIED 5


SMOS System Management to Operating System

RE Resource Element

TC Transfer Channel

VC Virtual Channel

NATO UNCLASSIFIED 6


5 Configuration/Reconfiguration Requirements

The flexible nature of integrated modular avionics allows the possibility for different mappings or configurations to be used, depending upon resources available or required functionality. The process of transition between such configurations is known as system reconfiguration.

In general, System Management controls all initial configuration and subsequent system reconfiguration activity. The System Management function is split into a platform dependent function, which is referred to as Application Management, and a Generic System Management function. While the Application Management controls the transition between Logical Configurations, the Generic System Management performs the actual configuration process. This configuration process is driven by information embedded in the Run-Time Blueprints. This information is generated using techniques such as those detailed in Section B.1.

System Configuration/Reconfigurations shall occur as a result of (see Figure 14):

- A change of System Mode. Application functions may request from Generic System Management a new Logical Configuration,

- The occurrence of a confirmed fault could occur at any time and, once verified, requires the system to be reconfigured,

- Ground crew maintenance and test actions,

- Phases of system initialisation and shutdown.

System Management

Power Initialisation+ Shutdown

Pilot/Application Mission Mode Management

Ground Crew ITM

Fault Fault Tolerance

Blueprints

System Design

Re/configuration Valid Avionic System State

Figure 14 – Re/configuration function and interfaces

In order to support certification of the system, it is highly important that the process of reconfiguration is provably predictable. Therefore, at any time, the state of the system must be known.

Each configuration within the Core system shall be identified in the RTBP for each level of the System Management hierarchy.

NATO UNCLASSIFIED 7


6 Concept

6.1 Configurations

6.1.1 Logical Configuration A Logical Configuration is a set of processes and their connections that defines the overall functionality for a given system or sub-system.

The logical configuration identifies for an application, all the necessary resources and how the processes are spread over the available IMA resources. Therefore a Logical Configuration also defines its associated resource requirements. For example:

- The types and number of Common Functional Modules (CFM) that are required,

- The number of needed Processing Elements (PE),

- The identification of Virtual Channels (VC) and their mapping to the Transfer Connections (TC).

The Logical Configuration addresses the operational application but also the ASAAC System Management hierarchy that is defined to managed these applications.

6.1.2 Physical Configuration A Physical Configuration is one implementation of a Logical Configuration. This means that all the detailed data, that were defined for the Logical Configuration are translated (instantiated) for the specific physical configuration.

These translated data are gathered into the Run-Time Blueprint.

Ultimately, in the ASAAC system, several Physical Configurations may be associated with one Logical Configuration.

6.1.3 Summary for Configuration Definitions The configurations of an ASAAC system are defined by:

- The operational/functional applications,

- The different system management hierarchies.

Both coexist throughout the mission time.

At run time, the Physical Configurations are defined in the Run-Time Blueprint and the System Management activates these configurations according to the System Management hierarchy by:

- The Integration Area (IA) Configurations,

- The Resource Element (RE) Configurations.

Further detailed information about System Management is to be found in volume 1 of this document, reference [6].

6.2 System States, Modes and Configurations

A mode for a system can be associated with one or more logical configurations, which is requested by the crew or operator by input via the application management. Changing from one mode to another may require a sequence of configurations to be applied. The mode of an entire system describes the running applications, as the system appears to the pilot or the operator. (Also fault management may trigger a mode change, if the system can only operate in a degraded mode).

NATO UNCLASSIFIED 8


Each System Mode is associated with one or more Physical Configurations where the assignment of the modules to integration areas and distribution of the applications on the modules is different without changing the external visible functionality. Configuration changes within one mode are generally the consequence of the fault management (see [6] Vol. 2).

6.2.1 Resource Element Configuration A RE configuration addresses all the physical configurations that have been defined for the considered Processing Element and that will be activated by the RE GSM of this PE during the mission life.

The RE configuration encompasses in the RTBP the necessary data for these physical configurations.

The whole of the software stack and applications define the actual configuration of the resource element.

6.2.2 Integration Area Configuration An Integration Area (IA) Configuration includes the physical configurations that are managed by the considered IA that belong to the system management hierarchy.

In practice, an IA GSM monitors and controls the loading and the activation of subordinate physical configurations defined for the mission life.

The state of an Integration area is reflected by the superset of the states of the associated RE-GSM together with the network interconnections.

The entire system state is now a superset of all subordinate IA states.

This subject is illustrated in the following picture:

RE1Conf -1

RE4Conf -2

RE3Conf -1

RE2Conf -1

IAConf-1

Figure 15 – Configuration of an IA as a composite of several RE

An AC-Level configuration is considered the highest-level IA.

6.2.3 States and Transitions The ASAAC architectural building blocks; processes, applications, PEs, IAs etc, can be considered to be in either a known state or in the process of transitioning from one known state to another known state. The transition process being instigated upon the receipt of a system event. this is shown in Figure 16.

NATO UNCLASSIFIED 9


Component

State 1

State 2

transition

Event-1

Event-2

Figure 16 – Generic State Transition of a component

In the transition from one state to another, the state machine performs actions. One of the actions can be the sending of an event to another object. In an ASAAC system, the actions are defined in the RTBP as action lists.

However, events are only taken into account when the transition has been completed and the component has reached a stable state.

Further detailed information about system states is to be found in volume 1 of this document, reference [6].

6.2.4 States of a compound Object during Reconfiguration A compound component, such as an IA, contains several components, which can be a subordinate IA or, at the bottom of the hierarchy, an RE.

The state of an IA can be expressed as superset of the objects contained. Figure 17 illustrates the State of an IA and its REs, including the state transition from state 1 to state 2. An illustrative example is given in the Appendix A.

It has to be noted that the whole IA is in a transition, where some components are still in a stable state. In a full sequential system, only one component is in a transition at a certain time. Such a system is always in a predictable state.



State 2

State 1

State 1.1

State 1.2

State 1.2

State 2.1

State 2.2

State 3.1

State 3.2

State 3.2

RE2-GSMRE1-GSM RE3-GSM

State 1

State 1.2

State 1.3

IA-GSM

State 1.1

State 2

State 2.1.1

State 2.1

State 3.1

Figure 17 – State Transitions of GSM components of an IA with 3 RE

In this sequence chart, the arrows indicate the messages which are exchanged between the managers. The vertical boxes represent the transitions, where the components execute actions from the RTBPs.

6.3 Reconfiguration

A reconfiguration is defined as the transient activity between two ultimate system states of the system, see volume 1 of this document, reference [6]. It is implemented by the action lists in the Run-Time Blueprints and is handled by the GSMs according to the System Management hierarchy.

6.4 Configuration/Reconfiguration Mechanisms and System Management

6.4.1 System Management Hierarchy The System Management Guidelines volume 1, reference [6] presents how a System Management hierarchy is constructed. This hierarchy uses Generic System Manager (GSM) components that can be configured according to three levels:

- Resource Element available on each Processing Element (PE) of the CFMs,



- Integration Area available building up the System Management hierarchy at one or more hierarchy levels,

- Aircraft uniquely available at the top of the hierarchy.

At run time, this GSM hierarchy implements Physical Configurations according to the IA/AC and RE configurations retrieved from the RTBP.

The key aspect of a configuration for an IMA system is the definition of the Integration Area (IA). An Integration Area is a logical grouping of functional applications which, as the name suggests, are closely integrated. They are identified using the Logical Configuration (see section 6.1.1).

A breakdown of the allocated functional application (FA) of a system is shown in the diagram below.

System

FA1 FA2

FA1.1 FA1.2 FA1.3 FA2.1 FA2.2

FA1.1 ... FA1.1.1 ... FA1.2.1 ... FA2.1.1 ... FA2.1.n FA2.2.1 ... FA1.3.1 ...

Functional Breakdownminimises the

influences between separate functions

at every level

Figure 18 – Example of the Functional Partitioning

The figure above illustrates the breakdown of a system into subsystems, which may be associated with the Integration Areas.

The selection of the scope and boundaries of individual Functional Areas are dependent upon the functional breakdown for a specific system and are, therefore, entirely at the discretion of the system designer.

The concept of an IA is intentionally flexible to allow a system designer to create core processing systems for the widest possible range of applications and platform types. The management of these applications is under the responsibility of an IA.

Within a System Management hierarchy the configuration changes can be triggered:

- By a super ordinate IA level GSM that uses the GLI command Stop/Load/Run Configuration,

- Internally to a GSM following Fault handling using a configuration change command (refer to the Fault Management Guidelines volume 2 ref [6]),



- On reply after a request to the GSM associated Application Manager using a SMLI command (refer to the System Management Guidelines volume 1 ref [6]).

The states for each level within the hierarchy have to be clearly identified taking into account the level of the impact on the GSM hierarchy and on the Integration Areas.

The configuration identification shall cover the necessary configurations for the GSM hierarchy and the configurations for the Integration Area encompassing the functional applications. They are all identified in the RTBP at run time.

6.4.2 Resource Allocation and Identification of the Configurations The Logical and Physical Configurations are defined according to the functional requirements and potential architectures for the considered IMA system. They have to take into account the policy for redundancy, spare resources, operational modes of the aircraft system and degraded configurations.

At run time, these Logical Configurations lead to a number of Physical Configurations (physical mappings) defined according to available capability of the architecture and associated resources of the considered IMA system. These mappings are encoded into the Run-Time Blueprints.

Scenarios such as the following ones have to be investigated:

- As components fail the fault management system will identify the failed component and access the Run-Time Blueprint for a physical configuration that does not use that component. A reconfiguration is then performed to stop the old configuration and start the new one. Hence the system can continue to perform its full logical functionality.

- An IA will contain a specific area of applications functionality. If this area of functionality is not required during a particular mission phase a similar process of reconfiguration can be performed to change to a Logical Configuration that does not include that IA functionality.

- If insufficient resources are available to perform the required functionality of a Logical Configuration then the system, triggered by fault management shall change to a Logical Configuration to perform a degraded version of the required functionality, using fewer resources.

The System Management concept only permits hierarchical links between a single IA to one or more Resource Element (RE) and not multiple links between one RE to different IAs. This implies, that only one IA GSM will control a set of RE for the configuration management. This is illustrated by the GSM hierarchy and resource allocation proposals below according to the previous functional application partitioning example from Figure 18.

The GSM hierarchy can exactly match the functional partitioning as shown in Figure 19. However, the GSM hierarchy can encompass several groups of functions from the detailed partitioning that results in reducing the number of IA, but increasing the complexity of these IAs. An alternative proposal is shown in Figure 20.



AC

IA1 IA2

IA1.1 IA1.2 IA1.3 IA2.1 IA2.2

RE7RE6RE5RE4RE3RE2RE1

FA1.1 ... FA1.1.1 ... FA1.2.1 ... FA2.1.1 ... FA2.1.n FA2.2.1 ... FA1.3.1 ...

Figure 19 – Proposal for Resource allocation and GSM hierarchy

AC

IA2

RE7RE6RE5RE3RE2RE1

FA1.1 ... FA1.1.1 ... FA1.2.1 ... FA2.1.1 ... FA2.1.n FA2.2.1 ...

FA1.3.1 ...

IA1

Figure 20 – Alternative proposal for Resource allocation and GSM hierarchy

6.4.3 Configuration for shared Resources The principles for managing the shared resources have been highlighted in the System Management Guideline volume 1 reference [6].

It is suggested that shared resources are managed by the lowest super-ordinate Integration Area level that encompasses these shared resources. The necessary shared resources configuration actions shall be triggered as part of the Configuration/Reconfiguration command.



6.4.4 Use of Spares for a new Configuration The principles for managing the spare resources have also been highlighted in the System Management Guideline volume 1 reference [6].

The spare resources can be handled within a low level Integration Area and in that case they are at disposal for this IA, or at a higher level IA and, in that case, a pool of spares is available for all the subordinate IA on request.

The necessary actions for requesting a spare resource, the initialisation of the module and the update of the GSM hierarchy (link of the newly GSM-RE to the existing GSM hierarchy) shall be established by a successive set of intermediate RE and IA configuration actions. These actions shall be available in the action list of the requesting IA as part of a receiving Configuration/Reconfiguration command.

This is described in volume 3 of this document, reference [6], that covers the initialisation of a subsequent CFM.

6.5 Configuration/Reconfiguration GLI Commands

This section aims to present the elementary actions that have to be undertaken in order to fulfil the configuration/reconfiguration commands as defined by the Standard for Software (ref [2]) for the GSM Logical Interface (GLI).

6.5.1 GLI Commands The configuration manager function of the GSM access to the RTBP (SMBP services) in order to get a list of actions that has to be performed on reception (from a super ordinate GSM) of one of the following GLI commands:

- Stopping Configuration

- Loading Configuration

- Running Configuration

The following reply messages are sent from the sub ordinate GSM to the super ordinate GSM:

- Configuration loaded

- Configuration stopped

- Configuration running

6.5.2 Actions The elementary actions, specified in the action list in the RTBP, have to be activated. Therefore the configuration manager function relates to the following activity:

- Process management that includes the creation of the processes and threads, the setting of the thread scheduling parameters, the run/stop/destroy of the processes.

- Communication management that includes the creation/deletion of the Virtual Channels (VCs), the creation/deletion of the Transfer Connections (TCs), the attachment/detachment of the VC to the Process/threads, the attachment/detachment of VC to TC and the configuration of the Interface for the TCs.

Some other services are available in the fields of the error handling and CFM services that are used by both the initialisation/shutdown mechanisms (see Guidelines volume 3 ref [6]) and the Fault Management (see volumes 2 and 3 of this document ref [6]) and therefore not covered by this volume.

The Figure 21 illustrates the grouping of actions according to the level of dependence impact within the system.



Process/Thread

Virtual channel

Transfer connection

Attachment to VC

Attachment VC to TC

SMOS_createVirtualChannelSMOS_destroyVirtualChannel

SMOS_attachChannelToProcessOrThreadSMOS_detachAllThreadsOfProcessFromVc

SMOS_createTransferConnectionSMOS_destroyTransferConnection

SMOS_attachTransferConnectionToVirtualChannelSMOS_detachTransferConnectionFromVirtualChannel

SMOS_configureInterfaceInterface for TC

SMOS_createProcessSMOS_destroyProcessSMOS_createThreadSMOS_setSchedulingParametersSMOS_runProcessSMOS_stopProcess

Figure 21 – Local RTBP actions grouped by activities

The first group gathers the process/thread and the VC to process attachment activity. Such activity is required for any configuration management whatever is the mapping of the application to the processing element (PE).

The second group cover the declaration of Virtual Channel activity. The related VC actions are dependent on the nature of the communication between the involved processes. When Intra Processor Communication (IPC) are used, the communicating processes are all mapped on a single processor so that the GSM-RE that create the needed VC at one time. In the cases of the other types of communication (IPEC, IMC, BMC), the involved processes are located on different PE, and so multiple GSM-RE are asked to create the needed VC at one time but on multiple location.

The third group covers the actions to be performed when there is a need for Transfer Connections (i.e. when IPEC, IMC and BMC are involved). In such a case, the actions have to be performed by different GSM-RE located on the same Processing Element as the communicating processes.

6.5.3 GLI Commands Action List The GLI command has a configuration parameter, which allows the use of the SMBP interface to retrieve the corresponding action list from the RTBP.

These action lists have to be defined by the system designer (who produces the RTBP) according to the expected behaviour for each of the GLI commands.

The “Loading Configuration” command is aimed to cover all the necessary actions required to prepare, to add a configuration or to change from one configuration to another one. For such behaviour, the following local actions can be used:

- For creating/adding a new configuration:

Creating Processes, Threads, VCs, and TCs

Setting Scheduling Parameters

Attaching VCs to Processes or Thread and TCs to VCs



Configure Interface

- For the change of configuration that involve the deletion of a former one and the preparation of a new configuration:

Detaching all Threads of Process from VC and TCs from VCs

Destroy Process, VCs, TCs

Creating Processes, Threads, VCs, and TCs

Setting Scheduling Parameters

Attaching VCs to Processes or Thread and TCs to VCs

Configure Interface

The “Loading Configuration” command can also require some actions to configure or initialise remote CFMs. There are services available for sending local configuration data to a remote CFM and for requesting status from a remote CFM.

They cover:

- The configuration of the Network (NSM),

- The loading of image (e.g. OS) to a remote CFM,

- The getting status of a remote CFM (PBIT, CFM status, CFM information),

- The getting of the network status and testing communication path (test message).

Except the first service, the others are used in the initialisation of IMA resources or the Fault Management (see respectively volumes 3 and 2 of this document ref [6]).

The “Running Configuration” command is aimed to trigger the execution of the loaded processes that only uses the following action:Running Processes

The “Stopping Configuration” command is aimed to stop some running processes and uses the following action:Stopping Processes

It may be considered that the “Stopping Configuration” includes the deletion of the referenced configuration to return to an implicit starting configuration (for example without any loaded application processes). In that case the following commands can be involved:

Stopping Process

Detaching all Threads of Process from VC, TC from VC

Destroying Process, VC, TC

Note that the execution of the actions may require a specific order that has to be followed in the RTBP action list definition.

6.6 Configurations managed within the GSM

The GSM performs several functions:



- Health Monitoring,

- Fault Management,

- Configuration Management,

- Security Management.

The configurations/reconfigurations are managed by the Configuration Management function that have to provide the other GSM functions with the configuration change information.

The Health Monitoring function needs to know which configuration the system is in, in order to select the appropriate error filters. It is the same for the Fault Management function that reacts to a specific configuration according to the raised error (that relates to this specific configuration).



7 Configuration/Reconfiguration Guidelines

7.1 System Behaviour and Configurations

GUI-CR_1: During a reconfiguration phase an IMA system is changing from one stable state to another. It is recommended to closely manage the intermediate states and to prevent any consequences of a hazard during these intermediate states.

GUI-CR_2: If an RE reconfigures locally (without notifying the IA), each configuration that can be loaded and run is limited to a set that does not impact the rest of the system.

GUI-CR_3: Upon the occurrence of a fault, the Fault Management function assesses the fault and maps it to a reconfiguration request. From Run-Time Blueprints provided data a new configuration shall be defined, which is acquired and started in order to mask the fault.

GUI-CR_4: For each fault condition, a reconfiguration procedure is necessary to ensure a new state is reached as quickly as possible to prevent propagation of the fault.

GUI-CR_5: It is likely to have multiple reconfigurations across the core processing system, within different IAs. The system designer will have to consider the global behaviour for reconfiguration actions within the system. This needs to handle the synchronisation mechanisms involved by the configuration that can be sequential or simultaneous among the IAs of a Core system.

GUI-CR_6: The system designer should define the type of control of reconfiguration progression that is required. This guideline is concerned with the time required to complete reconfiguration where two alternatives can be defined:

- Allow an independent parallel progression of different actions, meaning allowing actions to take place as soon as possible. This is more flexible and may be used for mission critical systems.

- Reconfiguration is finished when all the actions have been completed sequentially and when a given (and predefined) period of time has passed since the reconfiguration was triggered. This design is less complex to perform and validate. It is a better solution for systems requiring higher confidence in behaviour such as safety critical functionality.

7.2 Configurations/Reconfigurations and the GSM Hierarchy

GUI-CR_7: It is recommended that the System Management functionality (hierarchy), including all levels of GSM, is configured on a PE before any applications are configured.

GUI-CR_8: It is recommended that all applications on a PE are removed before its System Management functionality (hierarchy) is reconfigured.

GUI-CR_9: The system designer should ensure that control of the system is managed and devolved using the Configuration Management at aircraft level, Integration Area level, and resource element level in a top down manner.

GUI-CR_10: The system designer should define the responsibility between the Application Management (AM) and the Generic System Management (GSM), in terms of control of the reconfiguration process.

GUI-CR_11: A reconfiguration may occur due to a mode change or occurrence of a fault. In case of a mode change, it is recommended that it is initiated by the AM.

GUI-CR_12: It is recommended that when reconfiguration only concerns core elements, reconfiguration can be under the total responsibility of the GSM. All relevant information are given by the Run-Time Blueprints.



7.3 Configurations for Spare and shared Resources

GUI-CR_13: The system designer can manage spare CFMs, to include the following strategies:

- All spares can be held at aircraft level. This means that when required, any spare can be used in any Integration Area. This ensures that no IA is denied a spare when one is available in the system.

- Spares can be allocated to a particular IA and only used in that IA. This means that spares can be reserved for the most critical areas.

- A mixture of the above. Some spares are reserved for critical IAs and some are held at the aircraft level for general use.

Management of spare CFMs is also presented in volume 1 of this document, reference [6].

7.4 System Design Process

GUI-CR_14: The system designer should ensure that all the configuration/ reconfiguration management data for a considered core system are defined and available in the Run-Time Blueprints.

GUI-CR_15: It is recommended that the design process shall take into account all possible system events when defining the configuration/reconfiguration process, so that all eventualities can be taken into account and analysed during design of the system. It shall never happen that a system is in a state where unexpected events occur.



Annex A (Informative)

Example of the Use of a Reconfiguration after a CFM Failure

A.1.6 Foreword

The following subsections provide an example of how a single configuration change in an IA may be developed by the use of a number of actions, operating serially and in parallel. The intention is simply to demonstrate the components of the reconfiguration concept, and no conclusion should be drawn regarding the configuration of the system, the use of spare modules, functional redundancy, or allocation of Integration Areas.

A.1.7 Example Actions for Reconfiguration of an Application to a Spare Module.

Figure A.9 shows a greatly simplified model of an IMA system which comprises two avionic racks.

Data NetworkRacks

CFM1REP1

CFM6REP2

CFM3REP2

CFM1REP2

CFM1REP2

CFM6REP1

CFM5REP1

CFM3REP1

CFM2REP1

Figure A.9 – Example System prior to Action Configuration Change

In this example, the system is designed as a redundant system with two redundant racks. CFM1 and CFM2 run as duplex redundant system, while the CFM3/REP2 runs as spare of CFM3/REP1. CFM5 and 6 are not relevant for this example.

For the example, a very simple logical model of the IA1 is used. It is assumed that the IA–GSM of this application runs on a different module (e.g. on CFM1).

Appl-1 Appl-2

IA1

VC3VC2VC1

Figure A.10 – Logical Model of Integration Area IA1

In this example only CFM3/REP1 and CFM3/REP2, belonging to IA1, as shown in Figure A.11, are taken into account.



AC

CFM3REP2

CFM3REP1

App1 App2 FA .... FA ...

IA-1

App1 App2

Figure A.11 – Resource Allocation of the Example

The resource allocation of this IA1 is illustrated in Figure A.11. Only CFM3/REP1 and CFM3/REP2 are taken into account.

After a detected fault on CFM3/REP1, the reconfiguration shall bring the system from the logical reconfiguration CF1 to CF2. These configuration is illustrated in Figure A.12.

Data NetworkRacks

CFM1REP1

CFM6REP2

CFM3REP2

CFM1REP2

CFM1REP2

CFM6REP1

CFM5REP1

CFM3REP1

CFM2REP1

Figure A.12 – Example System after the Reconfiguration Process

This example demonstrates the configuration of this simplified system prior to the occurrence of an unspecified hardware fault. This fault affects the module hosting CFM3/REP1 and is detected by instances of fault management in both the IA-SM (which is alerted by BIT), and AC-SM (which is alerted by voter/cross monitors located in the other cross voting modules). The principles of fault management and methods for containing such a fault are described in detail in volume 2 of this document, reference [6].and are not considered in this example.

A.1.8 Implementation of the Reconfiguration Process

The following sequence describes the reconfiguration process, which is represented graphically in Figure A.13 and Figure A.14 respectively.

It illustrates how the actions, needed for the reconfiguration are composed of several smaller actions distributed over several CFMs. This reconfiguration sequence is decomposed into several smaller



state transitions. These intermediate states are used as synchronisation points for the actions, which take place on different CFMs.

Figure A.13 and Figure A.14 show the reconfiguration sequence with a strong sequential implementation (Figure A.13) and a parallel reconfiguration (Figure A.14) on different CFMs.

The shown reconfiguration is triggered by the fault management in state 1 of the IA.

State 1

stopped

State 2

run

stopped

spare

loaded

run

CFM3/REP1IA-1 CFM3/REP2

State 2

State 1

GLI_Stop_Configuration

GLI_Load_Configuration

stopProcess Appl-1stopProcess Appl-2detachAllThreadsOfProcessFromVcdetachAllThreadsOfProcessFromVcdetachTransferConnectionFromVirtualChanneldestroyVirtualChannel VC-1destroyVirtualChannel VC-2destroyVirtualChannel VC-3destroyProcess Appl-1destroyProcess Appl-2

createProcesscreateProcesscreateVirtualChannelcreateVirtualChannelcreateVirtualChannelattachChannelToProcessOrThread VC-1attachChannelToProcessOrThread VC-2attachChannelToProcessOrThread VC-3attachTransferConnectionToVirtualChannel VC-1attachTransferConnectionToVirtualChannel VC-2

runProcess Appl-1runProcess Appl-2

GLI_Run_Configuration

loadedGLI_Configuration_Loaded

GLI_Configuration_Stopped

Figure A.13 – System Reconfiguration with strong sequential Action Sequences



State 1

loaded

State 2

run

stopped

spare

loaded

run

CFM3/REP1IA-1 CFM3/REP2

State 2

State 1

GLI_Stop_Configuration

GLI_Load_Configuration

stopProcess Appl-1stopProcess Appl-2detachAllThreadsOfProcessFromVcdetachAllThreadsOfProcessFromVcdetachTransferConnectionFromVirtualChanneldestroyVirtualChannel VC-1destroyVirtualChannel VC-2destroyVirtualChannel VC-3destroyProcess Appl-1destroyProcess Appl-2

createProcesscreateProcesscreateVirtualChannelcreateVirtualChannelcreateVirtualChannelattachChannelToProcessOrThreadattachChannelToProcessOrThreadattachChannelToProcessOrThreadattachTransferConnectionToVirtualChannelattachTransferConnectionToVirtualChannel

runProcess Appl-1runProcess Appl-2

GLI_Run_Configuration

Figure A.14 – Reconfiguration with several parallel Atomic Actions

For simplicity, the following assumptions are made:

• The spare module is powered,

• The external communication is already redundant,

• GSM components are not affected.

It can be seen that the reconfiguration process in Figure A.14 incorporates parallel threads on different CFMs of smaller actions that also incorporate sequential actions.

The action lists, to move from one state to another, is therefore simply a set of actions which are implemented in the run time blueprints.



Annex B (Informative)

Examples for Configuration/Reconfiguration Sequences

B.3. Guidelines for Configuration/Reconfiguration Sequences

The ASAAC concept is, that all configurations and transitions between these configurations will be defined at design time. They are exclusively defined in the blueprints.

Run time Blueprints (RTBPs) is that part of the blueprints, which are available during operation of the ASAAC system, used by the Generic System Management functions (GSM).

B.3.1. Initial Configuration After power up and loading of the OSL, the first configuration of a RE shall be achieved by establishing this configuration from the RTBP. This includes all default communication channels to the outside, GSM on RE level, GSM on IA and AC level if it is defined in the blueprints, Application Processes and the communication in between.

This configuration is entered as static tables in the RTBP. The sequence of installing this configuration is hard coded in the RE Configuration Management in a defined way.

B.3.2. State Transitions after initial Configuration All state transitions are exclusively described in the run time blueprints. ASAAC implements no algorithm at run-time to investigate from a set of configurations the most appropriate.

These configurations can be reached by action lists in the RTBP as defined at design time. The action lists consist of information like:

- Establishment of processes and their threads,

- Destroy of processes and their threads,

- Creation and deletion of communication interfaces,

- Sending of messages to other GSM components,

- Reception of messages from other GSM components.

Description of the communication and trigger messages between GSM entities are described in the GLI Interface.

B.3.3. Reconfiguration Sequence on RE Level Reconfigurations may be either synchronised (Lock Stepped) or not (Single Trigger).

Which type of configuration change will be performed is defined at design time and contained within the action lists of the RTBP. Dependent on the different types of reconfiguration and the given complexity of a modular system it is up to the decision of the system designer to select one or the other mode.

B.3.3.1. Synchronised Synchronised reconfiguration includes:

- Stop all application processes on the associated CFMs,



- Load new application processes on the associated CFMs,

- Run application processes simultaneously.

With synchronised reconfiguration the time taken for reconfiguration is well defined and the behaviour during reconfiguration is known. These parameters are not well defined for non-synchronised reconfiguration.

B.3.3.2. Non-synchronised Non-synchronised reconfiguration triggers the reconfiguration with only one message. The applications on the CFMs start when the loading is finished.

Non-synchronised reconfiguration is used when:

- Configuration change involves only one RE,

- Running functional applications are not affected, but communication channels are,

- Functional applications are robust against interruption of communications, but have sensible data stored locally.

In order to perform a non-synchronised reconfiguration of an IA, the IA GSM may in turn use either method of reconfiguration to perform the reconfiguration of its subordinate IAs, where required.

B.3.3.3. Generic Sequence for Synchronised Reconfiguration of Subordinate Configurations This section describes a common sequence of actions for performing a synchronised reconfiguration of an RE or a subordinate IA: this is then referred to under the descriptions of the various non-synchronised IA configuration change functions.

Where multiple subordinate configurations are to be changed, they may be performed either in series or in parallel.

The principal sequence of events is that a super-ordinate instantiation first sends commands to the subordinate instantiation and waits for acknowledgement before the next command is sent.

The following activity diagram in Figure B.1 describes the sequence for a reconfiguration. The IA or AC Configuration Management which controls the RE uses a GLI command to initiate the stopping of the configuration of the RE and waits for an acknowledgement of success from the RE Configuration Management.



Stop Configuration

Configuration Stopped

Load Configuration

Configuration Loaded

Run Configuration

Configuration Running

Init Reconfiguration

End Reconfiguration

Initialisation of synchronised Reconfiguration

End of synchronised Reconfiguration

Stop Configuration

Configuration Stopped

Load Configuration


Run Configuration

Configuration Running

Subord. IA / RE GSMsIA GSM

Figure B.1 – Generic Sequence for Synchronised Change of Subordinate Configurations

B.3.3.3.1. Activity Diagram to stop a Configuration

The following activity diagram in Figure B.2 shows how to stop a configuration.



Stop Configuration

Configuration stopped

All concerned Applications stopped

Stop Configuration

Stop all concerned Application

Stop all concerned Applications

RESuperord. AC / IA GSM

Figure B.2 – Generic Sequence to stop a RE configuration

B.3.3.3.2. Activity Diagram to load the new Configuration

The RE Configuration Management removes a subset or the complete set of applications of the loaded configuration, and loads all applications which are not currently loaded but are part of the requested configuration onto the relevant hardware resources, including establishing the appropriate mapping of VCs onto TCs.

After that the controlling manager is informed of the completion of the operation.

LoadConfiguration

ConfigurationLoaded

Load Configuration

Unload UnusedComponents

Load NeededComponents

Unload UnusedComponents

Load NeededComponents



Figure B.3 – Load RE Configuration

B.3.3.3.3. Run RE Configuration

The IA or AC Configuration Management controlling dependent IA or REs uses the GLI command to initiate the synchronised start of the new configuration and waits for an acknowledgement of success from the IA or REs Configuration Management.

The RE Configuration Management initiates the start of the functional application processes by applying new scheduling data from the blueprints.

The controlling manager is informed accordingly.



Run Configuration

Activate All ConcernedApplications

Activate All ConcernedApplications

RunConfiguration

ConfigurationRunning



Figure B.4 – Run RE Configuration

B.3.4. Restart a Process after Application Failure After a detected failure of a functional application, which resulted in an interruption of this process, the RE Configuration Management accepts a ‘restart process’ request from the FM.

Note: The use of this functionality is system and application dependent. It may not be used if the process has synchronisation points with other processes.

The RE Configuration Management stops, destroys, loads and starts the relevant process using SMOS commands.

Change Configuration Restart Process

destroy Process

reload Process

destroy Process

reload Process

Process Restarted

RE (CM)RE (FM)

Figure B.5 – Restart Process

B.3.5. Cascade of Reconfiguration It is possible to cascade the configuration change over several hierarchies of IA levels.

The following sequences are related to section B.3.3, but the configuration is propagated across additional IA levels.

B.3.5.1. Stop IA Configuration The IA Configuration Management sends commands to stop relevant subordinate configurations as required and awaits their acknowledgement. One or more of the following commands is used:

- Stop IA Configuration,

- Stop RE Configuration.

Note: it is not required that all subordinate configurations are stopped.



The acknowledgement for the stopping of the IA configuration is sent back to the super ordinate manager.

ConfigurationStopped

StopConfiguration


StopConfiguration


StopConfiguration

Subord. IA / RE GSMIA GSMSuperord. AC / IA GSM

Figure B.6 – Stop IA Configuration

B.3.5.2. Load IA Configuration The super-ordinate IA or AC Configuration Management uses the GLI to initiate a configuration load and waits for an acknowledgement of success from its subordinate manager.

In Figure B.7 an example of loading a new IA configuration is shown. The IA Configuration Management sends commands to one or more subordinate configurations and awaits acknowledgement. One or more of the following commands is used:

- Load IA Configuration of a subordinate IA (as shown in activity diagram),

- Load RE Configuration (as shown in activity diagram),

- Change PCM Switch Configuration,

- Change NSM Switch Configuration.

The acknowledgement for the completed IA configuration load is sent back to the super-ordinate manager.

The IA configuration has been loaded: the relevant applications are located on the relevant REs and the communication structure has been established accordingly.

The super ordinate manager has been notified about successful IA configuration load.



ConfigurationLoaded

LoadConfiguration Load

Configuration

ConfigurationLoaded

LoadConfiguration

ConfigurationLoaded

Subord. IAIA GSMSuperord. AC / IA GSM

Figure B.7 – Load IA Configuration

B.3.6. Run IA Configuration The super ordinate IA or AC Configuration Management uses a GLI command to start an already loaded IA configuration and waits for an acknowledgement of success from its subordinate manager.

In Figure B.8 an example for running a new IA configuration is shown. The IA Configuration Management sends commands to run the respective subordinate configurations and awaits their acknowledgement. One or more of the following commands is used:

- Run IA Configuration of a subordinate IA,

- Run RE Configuration.

The acknowledgement of the running IA configuration is sent back to the super ordinate manager.


RunConfiguration Run

Configuration


RunConfiguration


Subord. IA / RE GSMIA GSMSuperord. AC / IA GSM

Figure B.8 – Run IA Configuration

B.3.7. Cascade of Configuration Change The super ordinate IA or AC Configuration Management uses a GLI command to initiate a non-synchronised change of IA configuration and waits for an acknowledgement of success from its subordinate manager.



The IA Configuration Management sends commands to one or more subordinate configurations and awaits acknowledgement. One or more of the following commands is used:

- Non-synchronised Change of IA Configuration of subordinate IA,

- Synchronised Change of IA Configuration of subordinate IA, using the generic sequence of Section B.3.5,

- Synchronised Change of RE Configuration, using the generic sequence of Section B.3.3.3,

- Change System Management Configuration,

- Change PCM Switch Configuration,

- Change Network Configuration.

The acknowledgement for the completed change of IA configuration is sent back to the super ordinate instance.

The IA configuration has been changed: the relevant GSM and application processes are located on the relevant REs and the communication structure has been established accordingly; the required scheduling table is set, and the processes are running.

The super ordinate manager has been informed about successful reconfiguration.

Change Configuration Generic

Reconfiguration

Configuration Changed


IA GSMSuperord. AC / IA GSM

Figure B.9 – Change of IA Configuration

Note: the GLI-command "Changing Configuration” (ID:EventId)" is used.

B.3.7.1. Change IA Configuration by FM The Fault Management initiates a non-synchronised change of IA configuration and waits for an acknowledgement from its Configuration Management.

Figure B.10 shows an example of an IA Configuration Management that sends commands to one or more subordinate configurations and awaits acknowledgement. One or more of the following commands is used:

- Non-synchronised change of IA Configuration of subordinate IA,

- Synchronised change of IA configuration of subordinate IA, using the generic sequence of section B.3.5,

- Synchronised change of RE configuration, using the generic sequence of section B.3.3.3,

- Change RE OSL configuration,



- Change PCM switch configuration,

- Change network configuration.

The acknowledgement for the completed change of IA configuration is sent back to the Fault Management.


Change Configuration Generic Triggered

or untriggeredReconfiguration


IA GSM (CM)IA GSM (FM)

Figure B.10 – Fault-Driven Change of IA Configuration

B.3.7.2. Change IA Configuration by the Application Management (AM) Mode changes of the system are initiated by the Application Management, resulting in new configurations of the Integration Areas. The AM itself is triggered by any crew actions or by any automatic mode change caused by the application.

AM uses an SMLI command to initiate a non-triggered change of IA Logical Configuration and waits for an acknowledgement of success from its Configuration Management.

Figure B.11 shows an example where the IA Configuration Management sends commands to one or more subordinate configurations and awaits acknowledgement. One or more of the following commands is used:

- Non-synchronised change of IA configuration of subordinate IA,

- Synchronised change of IA Configuration of subordinate IA, using the generic sequence of section B.3.5,

- Synchronised change of RE configuration, using the generic sequence of section B.3.3.3,

- Change RE OSL configuration,

- Change PCM switch configuration,

- Change network configuration.

The acknowledgement for the completed change of IA configuration is sent back to the AM.

As a result the IA configuration has been changed: the relevant GSM and application processes are located on the relevant REs and the communication structure has been established accordingly; the required scheduling table is set, and the processes are running.



Request LC Change

Generic TriggeredReconfiguration

Configuration ChangedLC

Changed

IA GSMAM

Figure B.11 – AM-Driven Change of IA Configuration



Study n°: Draft n°: I01 Date: 23/11/03 Step n°:

ENGLISH VERSION

ASAAC Phase II

Final Draft of Proposed Guidelines for System Issues Volume 5: Time Management

Dernière proposition des directives pour les aspects système – Volume 5: Gestion du Temps

Entgültiger Entwurf der Richtlinien für Systemaspekte – Band 5: Zeitmanagement

NATO UNCLASSIFIED

NATO UNCLASSIFIED

STANAG 4626 (Part VI) (Draft 1)

Contents

0 Introduction............................................................................................................................. 1 0.1 Purpose ................................................................................................................................... 1 0.2 Document structure ............................................................................................................... 1 1 Scope....................................................................................................................................... 3 2 Normative references............................................................................................................. 4 3 Terms, definitions and abbreviations................................................................................... 5 3.1 Terms and Definitions............................................................................................................ 5 3.2 Abbreviations.......................................................................................................................... 5 4 Requirement for Time Management ..................................................................................... 7 5 Time Management Concept................................................................................................... 8 5.1 Time references ...................................................................................................................... 8 5.1.1 Absolute Global Time (AGT) ................................................................................................. 8 5.1.2 Absolute Local Time (ALT).................................................................................................... 8 5.1.3 Relative Local Time (RLT) ..................................................................................................... 9 5.1.4 Performance parameters ....................................................................................................... 9 5.2 Clock concept ......................................................................................................................... 9 5.2.1 Master Reference Clock (MRC) ...........................................................................................10 5.2.2 Reference Clocks (RCs).......................................................................................................10 5.2.3 Module Clocks (MCs) ...........................................................................................................11 5.2.4 Clock initialisation................................................................................................................11 5.3 Distribution & Synchronisation .........................................................................................11 5.3.1 Distribution mechanism.......................................................................................................11 5.3.2 Synchronisation methods ...................................................................................................11 5.3.3 Time update method ............................................................................................................14 5.3.4 Fault Tolerance .....................................................................................................................15 6 Guidelines for Time Management.......................................................................................16 6.1 Guidelines for Time references...........................................................................................16 6.1.1 Absolute Local Time ............................................................................................................16 6.1.2 Absolute Global Time...........................................................................................................16 6.2 Guidelines for Time management methods ......................................................................16 6.2.1 General ..................................................................................................................................16 6.2.2 Synchronisation methods ...................................................................................................16 6.2.3 Communication mechanisms supporting Time distribution/synchronisation ..............16 6.3 Guidelines related to Clocks and Clock hierarchy ...........................................................17 Annex A (informative) Clock Synchronisation method without convergence functions .........18 Annex B (informative) Clock synchronisation methods with convergence functions .............31 Annex C (Informative) Time definitions and properties ...............................................................45

NATO UNCLASSIFIED

1

NATO UNCLASSIFIED


List of Figures Figure 1 - ASAAC Standard Documentation Hierarchy................................................................... 1 Figure 2 - Document Structure........................................................................................................... 2 Figure 3 - Clock hierarchy in an IMA system..................................................................................10 Figure 4 - Request-Reply mechanism for synchronised clock (ALT) ..........................................13 Figure 5 - Distribution of AGT time signals ....................................................................................14 Figure 6 - Active Follow time update principle...............................................................................14 Figure A.1 - Time management principle sequence for the AGT distribution process .............19 Figure A.2 - Time management principle sequence for the ALT synchronisation process ......20 Figure A.3 - Estimation of the Parent Clock time value.................................................................28 Figure A.4 - Update of the local ALT ...............................................................................................29 Figure B.1 - Clock Synchronisation functions ...............................................................................32 Figure B.2 - Reference values in a decentralised structure..........................................................38 Figure B.3 - Adjusting Instant computation principle ...................................................................40 Figure B.4 - Deviation function principle ........................................................................................41 Figure B.5 - Adjusting function principle........................................................................................44

List of Tables Table 1 - Time resolution requirements of subsystems.................................................................. 7 Table 2 - Typical characteristics ........................................................................................................ 9 Table A.1 - Reset cases for the RLT and ALT.................................................................................26 Table A.2 - RTBP Time mgt data summary table ...........................................................................27 Table A.3 - Time types and resolution (requirement) ....................................................................30 Table B.1 - Reference function convergence types.......................................................................35 Table B.2 - Remote clock techniques and latency bounds...........................................................37

NATO UNCLASSIFIED

2

NATO UNCLASSIFIED


1 Introduction

1.1 Purpose


The purpose of the ASAAC Programme is to define and validate a set of open architecture standards, concepts & guidelines for Advanced Avionic Architectures (A3) in order to meet the three main ASAAC goals. 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:














Figure 12 - ASAAC Standard Documentation Hierarchy

1.2 Document structure


NATO UNCLASSIFIED

1

NATO UNCLASSIFIED


Section 2, scope of the document

Section 3, normative references

Section 4, the terms, definitions and abbreviations,

Section 5 gives the ASAAC requirements for the time management within a avionic system,

Section 6 gives the concept specification for the time management,

Section 7 gives the guidelines for the time management concept implementation.

The following annexes are attached to this volume:

0 gives the informative time management specification that have been implemented onto a core processing demonstrator,

Annex B provides summary of documentary research and study work about synchronization with convergence function methods,

Annex A provides some time definition and properties.

ScopeScope

Section 1


Section 2


Section 3

Time Management Requirements

Time Management Requirements

Section 4

Time Management Concept

Time Management Concept

Section 5

Time References

Time References

Time Management

Methods

Time Management

Methods

Clock Concept

Clock Concept

Time Management Guidelines

Time Management Guidelines

Section 6

Time References

Time References

Time Management

Methods

Time Management

Methods

Clock hierarchy

Clock hierarchy

Volume 5Time Mangement

Volume 5Time Mangement

Proposed Guidelines for System Issues

Figure 13 - Document Structure

NATO UNCLASSIFIED

2

NATO UNCLASSIFIED


2 Scope

The ASAAC concepts and ASAAC standards mandate the functionality and in some cases the implementation of that functionality that a system must adopt in order for it to be considered 'ASAAC compliant'. However, in addition to these standards and concepts, the ASAAC Programme has also defined a series of guidelines which although not mandated are offered in order to support the ASAAC system integrator in defining and building a system. These guidelines represent the findings of the ASAAC Team during the validation phase of the Programme during which representative systems were designed and implemented in order to validate the standards and concepts.


This volume is the firth of the seven volumes of Final Draft of Guidelines for System Issues, which have been introduced within the Architecture Standard:

It gives the time management concept applicable to an IMA System for aerospace applications in section 6.

It gives guidance for implementation of time management and clock hierarchy for an IMA System for aerospace applications in section 7.

NATO UNCLASSIFIED

3

NATO UNCLASSIFIED


3 Normative references

A) References to published standards None. B) References to standards in preparation 7. Final Draft of Proposed Standards for Architecture

Document ref.: ASAAC2-STA-32460-001-CPG






C) References to other documents None. D) References to documents from other organisations (selected US standards as stated above) None.

NATO UNCLASSIFIED

4

NATO UNCLASSIFIED


4 Terms, definitions and abbreviations






4.2 Abbreviations

AGT Absolute Global Time

AL Application Layer

ALT Absolute Local Time

APOS Application to OS Interface

ASAAC Allied Standard Avionics Architecture Council

CBIT Continuous Built in Test

CCPP Common Core Processing Platform

CET Central European Time

CFM Common Functional Module

CNI Communication Navigation Information

CPP Core Processing Platform

DPM Data Processing Module

EO Electro-Optics

EW Electronic Warfare

GMT Greenwich Mean Time

GPM Graphics Processing Module

GPS Global Positioning System

GSM Generic System Manager

HM Health Monitor

IMA Integrated Modular Avionics

MC Module Clock

NATO UNCLASSIFIED

5

NATO UNCLASSIFIED


MI Minimum Interval

MLI Module Logical Interface

MMM Mass Memory Module

MOS MSL to OSL Interface

MRC Master Reference Clock

MSL Module Support Layer

NSM Network Support Module

OM Oral Message

OSL Operating System Layer

PBIT Power up/Power down Built in Test

PCM Power Conditioning Module

PE Processing Element

RC Reference Clock

RLT Relative Local Time

RTBP Run Time Blueprint

SM Signed Message

SPM Signal Processing Module

TC Transfer Connection

TLS Three Layer Stack

UTC Coordinated Universal Time

VME Versatile Module Europa

NATO UNCLASSIFIED

6

NATO UNCLASSIFIED


5 Requirement for Time Management

IMA Systems require the concept of a distributed ‘Time’ reference in order to facilitate the following:

• The co-ordination of multiple aircrafts taking part in the same mission,

• The recording of the time when system events occurred. (i.e. Fault Management),

• The recording the time when data arrives in and/or leaves a system. (I.e. Time Stamping),

• The scheduling of system management and functional application processes. (To cater for a range of scheduling algorithms),

• The synchronisation of separate subsystems within a system.

Examples of typical requirements for time resolution1 for current subsystems are collated in Table 1.

Table 1 - Time resolution requirements of subsystems

Sub-system Time Stamping of Data and Events

Scheduling of Processes

Synchronisation of Processes/Tasks

Radar 0.05 ms 0.05 ms 1 ms

EW 0.1 ms 0.1 ms 0.05 ms

EO 0.2 ms 1 ms 1 ms

CNI 10 ms 10 ms -

Sensor/Data Fusion 1 ms - 0.1 ms

Vehicle System - 1 ms 0.001 ms

The implementation of such a concept shall ensure that:

• The distribution of ‘time’ throughout the system shall be such that the maximum difference of the time values of any single event observed from two different processing elements is bounded by a known constant (project specific),

• The system time mechanisms shall be chronoscopic, i.e. the consecutive time values shall not stand still or be decremented,

• The drift of clocks shall be bounded by a known constant (project specific).

• The solution shall be fault tolerant,

• Time references must be available to applications as an operating system function call.

1 Resolution is the minimal time interval between two consecutive time values (ticks).

NATO UNCLASSIFIED

7

NATO UNCLASSIFIED


6 Time Management Concept

Time management is concerned with the generation, distribution and synchronisation of timing signals throughout an IMA system.

The time management concept is based on:

• The use of the IMA System network (asynchronous) as defined by the Network standard (see ref [9]),

• The Module Physical Interface provided by the CFM as defined by the Packaging standard (see ref [11]).

The Time Management Concept meets the requirements identified in section 5 through the use of:

• Three different time references,

• A Clock Hierarchy comprising three different types of clock,

• Distribution and synchronisation methods.

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

6.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 (GMT, CET etc.).

The resolution and accuracy will be constrained by that of the data transmitted to the aircraft from sources such as GPS. Since knowledge of AGT is required to synchronise external communications, the minimum expected resolution is 1ms.

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 application layer and the operating system layer,

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

6.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 higher resolution than AGT, and as such, it can be used by functional applications requiring high levels of synchronisation such as the implementation of multiple redundant processing lanes.

NATO UNCLASSIFIED

8

NATO UNCLASSIFIED


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 CFMs that form the IMA System to cope with the system (global) time resolution requirement,

• Distributed/synchronised using a hierarchy of clocks, which is described in section 6.2,

• Independent from the AGT,

• Made available to the OSL and Application Layer through the use of MOS and APOS services.

6.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 Application Layer 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.

6.1.4 Performance parameters The expected performance parameters for the three time references are summarised in Table 2 below.

Table 2 - Typical characteristics

Type Resolution Roll over

Absolute Global Time 1 - 10 ms > 60 days

Absolute Local Time 0.001 - 0.1 ms Daily

Relative Local Time < 0.001 ms < 60 seconds

The accuracy of the time value should be much higher than the resolution being in the range of +/- 0.01%.

6.2 Clock concept

Each CFM will host a physical entity that delivers physical clock ticks. The clock concept defines several clocks that will be used to build a hierarchy for the purpose of managing and distributing a time reference throughout the system. During the system initialisation process, blueprint information will determine the position of a particular clock in the hierarchy in terms of its assuming the functionality of either a:

• Master Reference Clock (MRC),

• Reference Clock (RC),

NATO UNCLASSIFIED

9

NATO UNCLASSIFIED


• Module Clock (MC).

An example is shown in Figure 14.

MRC(MMM)

MRC(MMM)

RC(NSM)

RC(NSM)

RC(MMM)

RC(MMM)

RC(NSM)

RC(NSM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

MC(CFM)

RC1

RC2RC3

RC4

Figure 14 - Clock hierarchy in an IMA system

Depending on the nature of the system network topology and the corresponding complexity of the Clock Hierarchy, the MRC may interact with RCs or directly with MCs. In very complex systems, RCs may be nested and therefore RCs may interact with lower level RCs or with MCs. However, the lowest level RCs must always interact with an MC.

6.2.1 Master Reference Clock (MRC) The most senior clock in the hierarchy. Each IMA system will comprise a single instance of MRC. The MRC is responsible for:

Accessing the AGT from the source (e.g. GPS), •

•

•

•

•

•

•

•

Generating the RLT that is also used for ALT,

Providing a means for distributing the AGT and ALT to its slave clocks, whether they are RCs or MCs,

Making all three time references available to its own OSL via the use of MOS services.

6.2.2 Reference Clocks (RCs) The RCs are responsible for:

Generating the RLT,

Maintaining the time references during the periods in between the receipt of the synchronisation messages sent to them by their MRC,

Providing a means for distributing the AGT and ALT to their slave clocks, whether they are RCs or MCs,


NATO UNCLASSIFIED

10

NATO UNCLASSIFIED


6.2.3 Module Clocks (MCs) MCs are the lowest level of clock within the hierarchy. They are responsible for:

Generating the RLT, •

•

•

Maintaining the time references during the periods in between the receipt of the synchronisation messages sent to them by their master clocks (MRC or RC).


6.2.4 Clock initialisation During the system initialisation the clock hierarchy is built and the MRC, RC and MC configured by the system management based on RTBP data.

Applying power to a CFM will result in:

• The CFM hosting the MRC setting:

• ALT to zero,

• Its version of RLT to zero.

• CFMs hosting RCs and MCs setting:

• Their version of RLT to zero.

Once the clock hierarchy has been established and ALT initialised, it can then be distributed to the underlying clocks in the hierarchy. Once this has been achieved, The MRC will access AGT and then provide the means for distributing it to its subordinate clocks.

6.3 Distribution & Synchronisation

The distribution and synchronisation methods for ALT and AGT are presented in the following subsections in order to present the context for time management methods and their links to the type of implementation that are presented in the Guidelines section 7.

6.3.1 Distribution mechanism Distribution mechanism covers the sending of time signal from a reference source towards a slave clock. This method can be used with a one way top-down sending protocol but requires that the latency in the distribution of signals throughout the system shall be such that the maximum difference of the time values of any single event observed from two different Processing Elements (PE) is bounded by a known constant (system time resolution).

To support the ALT time management and comply with higher resolution requirements, this method can be used together with a highly deterministic hardware facilitated by a synchronous network that shall be considered as an inherent part of the ALT time reference source (out of the scope of this guideline).

6.3.2 Synchronisation methods Clock synchronisation allows, despite skews of the physical clocks from the different sites, the ability to maintain a common system (global) time of which the values (time) over the system are approximately equivalent i.e. within the system time resolution.

Synchronisation methods can be implemented by hardware, software or hybrid (a mix of the two) solutions.

NATO UNCLASSIFIED

11

NATO UNCLASSIFIED


Hardware methods directly correct the physical clock parameters (e.g. drift rate) in order to be synchronised with a time reference. The system time is directly delivered by the physical clock. Hardware solutions uses dedicated circuits and buses that provide better accuracy (clock skew) than software solution. However the cost is high and they are only retained for high quality time accuracy,

Software synchronisation uses a physical clock or timer to update one or more synchronised clock(s). The synchronised clock is a physical clock on which synchronisation algorithms are applied to provide the system with a (almost) synchronised time to a time reference (e.g synchronised clock drift rate is corrected). Software implementation uses exchange of message (request-reply mechanism) between the system sites via a communication network. These solutions are flexible and cheaper than hardware solutions but necessitate bus bandwidth and messages that decrease the time accuracy. The software synchronisation methods can implement mechanisms using algorithms with or without convergence features:

- Algorithms without convergence use a single clock as the time reference at the top of a clock hierarchy,

- Algorithms with convergence (which can be applied at every level of the clock hierarchy) within a group of clocks is used to define a common time reference. This common time reference is used for clock update within the clock hierarchy. This requires extra message exchanges between the different clock sites. This type of algorithms is detailed in Annex B.

Hybrid solutions aim to increase software solution accuracy and reduce the cost of hardware equipment.

The methods to use for time management shall result in a trade-off between the compliance to the ASAAC standard (software methods) and level of requirement for system time accuracy (hardware methods). This is dependent on a specific project. Synchronisation method mechanisms without convergence are provided in the following subsections (see also 0).

6.3.2.1 Request-Reply mechanism for synchronised clock (ALT) The request-reply communication mechanisms for synchronised clocks supporting the ALT as the time reference is presented below.

This communication scheme (see Figure 15) is applicable to synchronisation methods without convergence. It is based on three stages:

The first one aims to initialise the synchronised clock with a value coming from the reference time source. This is required to have the remote synchronised clock mechanism using the same time as the reference time source,

The next stage aims to request to the reference time source for a triggering top (start time) that will be used to trigger the periodical time reference value requests,

The last stage covers the periodical request-reply exchanges that deliver to the remote synchronised clock the time reference values and allow it to update the synchronised clock parameters.

NATO UNCLASSIFIED

12

NATO UNCLASSIFIED


Time reference(MRC or RC)

Federated Remote Clock(RC and MC)

Request value of time reference

Initialise theSynchronised Clockwith the received value

Reply with start time for triggeringremote synchronisation process

Loop until availability

Reply with time reference value

Remote Clock Synchronisation parameter update

Ready for synchronisation


Trigger at start time theTime reference request

Reply with time reference value


Reply with time reference value Remote Clock Synchronisation parameter update

Start time

Start time + Period

…

Figure 15 - Request-Reply mechanism for synchronised clock (ALT)

The distribution delays can be calculated remotely and each synchronised clock can add the appropriate amount to the received time.

6.3.2.2 Distribution of reference time offset (AGT) The distribution of reference time offset is basically used to retrieve the AGT value from the synchronised ALT time value within a remote CFM.

The offset or the couple of initial values for the AGT and ALT from the MRC can be used as time signal and sent only one time or several times according to operational requirements.

The communication scheme is the same as for the distribution of reference time signals (see Figure 16).

NATO UNCLASSIFIED

13

NATO UNCLASSIFIED


Time reference(MRC)

Remote Clock(MC)

AGT/ALT offset Transmission Remote Clock

Computation for AGT

Time reference(MRC)

RemoteMC

Remote RCComputation for AGT

RemoteRCs

AGT/ALT offset Transmission

AGT/ALT offset Transmission Remote RC

Computation for AGT

Case ACase AMRC MRC to MC hierarchy linkto MC hierarchy link

Case BCase BMRC MRC to RC & RC to MCto RC & RC to MC

hierarchy linkhierarchy link

Figure 16 - Distribution of AGT time signals

6.3.3 Time update method Active re-synchronisation generally takes the form of actively re-calibrating local time slope whenever the time is received, providing a damping effect of the drift. When a time update is received active resynchronisation will compare the received time with the maintained time. A damping adjustment is calculated from the difference and applied. This process is known as active synchronisation with follow, shown in Figure 17.

Standard Time ( MRC )

Local Clock Time

Theoretical Time

Drift

Drift becomes dampedoscillation

Active - Follow

Figure 17 - Active Follow time update principle

NATO UNCLASSIFIED

14

NATO UNCLASSIFIED


This damping occurs quickly, certainly within the first few minutes after system initialisation. Also, as temperature changes etc. alter the drift of the local clock, active re-synchronisation follows the drift quickly, hence causing few inaccuracies.

6.3.4 Fault Tolerance The proposed concept shows a major advantage in tolerance of the MRC to transient faults. Free running high-resolution clocks on modules, periodically synchronised to the MRC, are essentially immune to temporary interruptions of the MRC update messages.

Should the MRC fail and miss several synchronisation messages, the local clocks continue, although they will eventually drift further than acceptable accuracy limits. As part of the specification, the limits on drift should be sufficient to allow several master synchronisation pulses to be missed. Also, under active re-calibration, once calibrated the local clocks will exhibit significantly less drift than under passive re-calibration.

If placed outside the core, the MRC may be connected via more than one signal concentrator to supply absolute local time to more than one avionics rack. This approach potentially improves the accuracy of the time distribution system, although is implemented primarily for reasons of fault tolerance. However, this again, is a platform specific decision.

NATO UNCLASSIFIED

15

NATO UNCLASSIFIED


7 Guidelines for Time Management

7.1 Guidelines for Time references

7.1.1 Absolute Local Time • ALT should serve as time source for non-core elements interacting with the core.

7.1.2 Absolute Global Time • Possible sources for direct supply of Absolute Global Time are:

Manually, e.g. pilot input,

Automatically from ground equipment,

From a globally available source, such as GPS.

• The distribution within an IMA system of AGT should be implemented using the local ALT time signals together with an offset from the MRC.

7.2 Guidelines for Time management methods

7.2.1 General • As part of the specification, the limits on the drift should be sufficient to allow several master synchronisation pulses to be missed.

• The system designer should ensure that the time distribution method is fault tolerant.

• The system designer should ensure that CBIT is used to test the validity of remote local ALT and associated synchronisation mechanisms.

• Information about the synchronisation mechanisms of all time sources should be contained in the blueprints.

7.2.2 Synchronisation methods • Two types of synchronisation methods for the ALT are proposed: with convergence and without convergence. It is recommended to implement a synchronisation without convergence algorithm (software solution) that is the cost-effective solution for an IMA System so far.

• The time management concept should implement a method that retrieve the AGT time signal from an offset associated to an ALT time signal (software solution) on each CFM.

7.2.3 Communication mechanisms supporting Time distribution/synchronisation • Time distribution/synchronisation has to use the existing network architecture, however the protocol structure in the MLI should be used.

• The system designer should consider the overhead of time distribution signals in the definition of logical and physical system configurations, to ensure predictability.

• The Request-Reply communication scheme for synchronised clock should be implemented for the ALT distribution/synchronisation as best cost/benefit solution (see section 6.3.2.1).

• The distribution of reference time offset communication scheme should be implemented for the AGT distribution/synchronisation as best cost/benefit solution (see section 6.3.2.2).

NATO UNCLASSIFIED

16

NATO UNCLASSIFIED


7.3 Guidelines related to Clocks and Clock hierarchy

• All modules should be included in the clock hierarchy.

• It is recommended that the clock hierarchy does not change during the mission time. Therefore Reference Clocks (RC) may be hosted on the module type of the initial cluster (i.e. MMM, NSM and PCM) and the Module Clocks (MC) hosted on the other modules (i.e. DPM, SPM & GPM).

• If a failure has been detected on the MRC, it is recommended to stop and reload a new clock hierarchy and reinitialise the AGT and ALT synchronisation processes (RLT is not affected once the CFM is not restarted).

• It is recommended that the clock hierarchy ischanged at system reconfiguration to minimize perturbation of time reference ALT synchronisation mechanism.

NATO UNCLASSIFIED

17

NATO UNCLASSIFIED


(informative)

Clock Synchronisation method without convergence functions

A.4. Foreword

This annex provides a summary of technical implementation specification for an IMA system demonstrator.

A.5. Time Management Specification

The implementation for time management methods uses:

Clock synchronisation without convergence function,

Clock update using an offset,

Active Follow time update principle.

A.1.9 Time management sequence overview An overview of the time management sequences is provided in this section that takes into account the MLI messages.

Two independent sequences are provided and required for the Core Processing platform implementation, which are:

The sequence for the distribution of the AGT over the clock hierarchy is provided in Figure A.1,

The sequence for the ALT synchronisation process over the clock hierarchy is provided in Figure A.2.

Note that the second sequence may be also applicable in principle to an AGT synchronisation process (with specific services/messages) but is not required for the Core Processing Platform implementation.

NATO UNCLASSIFIED

18

NATO UNCLASSIFIED


Figure A.1 - Time management principle sequence for the AGT distribution process

NATO UNCLASSIFIED

19

NATO UNCLASSIFIED


Figure A.2 - Time management principle sequence for the ALT synchronisation process

A.1.10 Absolute Global Time distribution process For the scope of the Core Processing Platform development and demonstration the AGT is delivered and available at the CFM level (locally) but not synchronised. The AGT time reference is received by the Master Reference Clock (MRC) CFM on request and when available it is stored to keep the external world time reference inside the ASAAC Core system. At the same time the MRC ALT time value (ALT0) is also stored to have the correspondence with the received AGT time reference.

The couple of value AGT0/ALT0 is available to the other CFMs on request according to request/reply sequence, which is activated periodically. Once the AGT0/ALT0 values are received in a slave CFM the request/reply process is stopped and the slave clock CFM stores locally the AGT0 and ALT0 time values.

Then the current AGT is retrieved from the stored couple of values AGT0/ALT0 and the current ALT time value by the following computation:

current AGT = current ALT + AGT0 - ALT0

Before having the couple of values AGT0/ALT0 the current AGT shall be considered as not available locally in the CFM.

NATO UNCLASSIFIED

20

NATO UNCLASSIFIED


The complete sequence is described in the Figure A.1.

A.1.11 Absolute Local Time Synchronisation Process overview The ALT synchronisation process described in this section is applicable for the distribution of the Absolute Local Time among all the CFMs. The synchronisation process implements a synchronisation without convergence (see algorithm in section A.7), is supportive to the pyramidal clock hierarchy (see Figure 14) and is similar between the MRC with its associated RCs and each RC with its associated MCs.

The synchronisation process is characterised by:

An initialisation step to retrieve for the first time the ALT time reference and to get the start time for the synchronisation process,

A periodical process that includes:

1. The triggering of the ALT synchronisation requests periodically according to a predetermined synchronisation wave period and a start time,

2. The analysis of the time (ALT) value difference between the parent and a slave clock in order to determine the synchronisation state of the slave clock,

3. The correction of the slave clock speed rate of the slave clock when de-synchronised.

A.1.12 Initialisation step for the ALT synchronisation process The ALT is a counter provided by the MSL software and is initialised as part of the MSL initialisation.

Two steps for its initialisation can be depicted:

1. Counter initialisation and configuration data have to be retrieved from the RTBP,

2. Before the OSL is available the ALT counter cannot be used because it is not synchronised with the system time (ALT) reference. The return status when the ALT time is requested shall be ‘unavailable’,

3. The slave Clock CFM requests its parent Clock CFM for the ALT time reference initialisation data.

For the last step the following sequence is needed:

1. The slave Clock (RC or MC) requests its parent clock (MRC or RC) for a first value: current Parent Clock ALT,

2. The Parent clock CFM transmits this first ALT time value to the slave clock CFM,

3. The slave clock CFM updates its current ALT counter with the received current ALT value from its parent Clock. (Note that a gap is created in the slave clock CFM for the ALT),

4. Once the step 3 is done the slave Clock CFM transmits a ready for ALT synchronisation message to its parent Clock CFM,

5. The Parent Clock CFM replies with a start for ALT synchronisation message that contains the start time (ALT value) for triggering the periodical synchronisation process (see section A.1.13).

Up to step 3 included the current ALT shall be considered as ‘unavailable’ locally.

NATO UNCLASSIFIED

21

NATO UNCLASSIFIED


A.1.13 Periodical sequence for the ALT synchronisation process The following steps are constitutive to the synchronisation process between the MRC and a slave RC (it is identical between a RC and its slave MC):

1. Each RC requests periodically the parent (MRC) ALT time value. The request message is time stamped with the local RLT in order to estimate the transmission delay at that time,

2. The parent (MRC) replies with its ALT time value (together with additional parameters if necessary). One assumes that the processing delay is neglected,

3. The RC receives the MRC reply and immediately gets the reception time from its RLT reference,

4. The go and return transmission delay is then computed from the RLT time values. One assumes that the go and return transmission delays are equal,

5. With the previous assumption it is possible for the slave RC to estimate the parent (MRC) ALT reference using the ALT time replied by the MRC and the computed one way transmission delay,

6. The difference of the ALT time values between the parent (MRC) and the slave RC is then computed,

7. This difference is used to determine the synchronisation status of the slave RC. Two ceilings are used:

- A time difference maximum bound beyond which the slave RC is not synchronised and an error is raised to the HM,

- The ALT system time resolution bound beyond which the slave RC is trying to be synchronised (if the time difference is below the maximum bound) or below which the slave RC is synchronised.

8. When necessary, the correction factor on the slave clock speed rate is computed and applied during the incoming synchronisation wave period (linear correction).

A.1.14 Relative Local Time Process The RLT is a counter provided by the MSL software and is initialised as part of the MSL initialisation. It uses the CFM timer to update the elapsed time. It starts with a nil value.

The RLT is not subject to synchronisation among the system.

Only the RLT value is allowed to be used until the ALT is ready for synchronisation.

A.1.15 CFM timer activation/reset Each CFM shall provide a physical clock also called a CFM timer in this implementation example.

Once a CFM is powered on the timer (the CFM physical clock) starts running. Then the timer shall deliver regular ticks internally to the CFM. PBIT functionality shall verify the CFM timer activity.

The reset of the CFM timer is possible on:

Power on of the CFM,

Hard reset of the CFM.

There is no reset of the timer on:

NATO UNCLASSIFIED

22

NATO UNCLASSIFIED


Soft reset of the CFM,

Watchdog reset.

A.1.16 CFM functionality for Time management The Relative Local Time and the Absolute Local Time are software counters implemented at the Module Support Layer (MSL) level.

The Relative Local Time is available in each of the ASAAC Core System CFMs.

The Absolute Local Time among an ASAAC Core System is defined on the basis of a hierarchy of clocks (see Figure 14) that includes:

A Master Reference Clock (MRC),

The Reference Clocks located into MMMs and NSMs,

The Module Clocks located into the other CFMs i.e. DPMs, SPMs, PCMs and GPMs.

For every CFM, the ALT and the RLT are started by the MSL during its initialisation sequence. At this time the ALT is not valid.

The Absolute Global Time is locally computed on the basis of the synchronised ALT according to initialisation data.

The following subsections provide the functionality details for each of the CFM cases.

A.1.17 Master Reference Clock CFM A.5.1.1. Initialisation/Configuration The Master Reference Clock (MRC) is one of the Reference Clocks and is the reference for the Absolute Local Time in the ASAAC Core system.

The identification of the MRC shall be done through the RTBP data (therefore the full TLS shall be operating).

In the RTBP loaded in the MRC module, the list of the CFMs that hold a RC shall be defined in order to establish appropriate TCs.

The initialisation of the MRC requires the following sequence:

During hardware boot the CFM timer is activated and its functionality verified (see section A.1.10),

To load and process the RTBP data for clock configuration,

To start the RLT with the predetermined time value (zero),

To start the ALT with the predetermined time value (zero),

To get with a request/reply sequence2 the AGT from the outside of the ASAAC Core system and store at its reception both the received AGT value (AGT0) and the corresponding MRC ALT value (ALT0). This couple of time values is denoted in the document AGT0/ALT0.

Since the MRC CFM TLS is not loaded and activated the broadcast of the ALT reference cannot start.

2 Note that this process is not necessarily attached to the MRC CFM initialisation.

NATO UNCLASSIFIED

23

NATO UNCLASSIFIED


A.5.1.2. Functionality At the nominal state, the MRC CFM shall provide the following functionality:

To maintain the Relative Local Time,

To maintain the Absolute Local Time reference,

To send the start time message to a CFM with a slave RC,, after receipt of readiness status message from that CFM,

To send on request the Absolute Local Time reference towards a slave Reference Clocks (RC),

To send on request the couple of values: stored AGT0/ALT0,

To compute the current AGT,

To transmit errors to the Health Monitor.

A.5.1.3. RTBP data For the Master Reference Clock CFM the following data have to be defined in the RTBP:

The RC identifier,

The MRC tag,

The structure for the slave RC CFMs (list of CFM_id + RC_id),

The synchronisation wave rate (frequency or period) for dysfunction control.

A.1.18 Reference Clock CFMs A.5.1.4. Initialisation/Configuration The modules that hold a Reference Clock are determined by system designer. Each of these modules need a list of slave CFMs defined in their RTBP. They also need the knowledge of the parent MRC CFM required by the time service initialisation.

The initialisation of the RCs requires locally the following sequence:




To send the request to the MRC for getting for the first time the current MRC ALT,

To start and initialise the ALT counter with the current MRC ALT time value,

To send the request to the MRC for getting the couple of time values (AGT0/ALT0),

To store locally the couple AGT0/ALT0,

To send to the MRC a readiness status for the ALT synchronisation process.

A.5.1.5. Functionality At the nominal state, each RC CFM shall provide the following functionality:

NATO UNCLASSIFIED

24

NATO UNCLASSIFIED


To maintain its Relative Local Time,

To send (periodically) a request to the MRC for getting the Absolute Local Time reference,

To receive the Absolute Local Time reference from the Master Reference Clock CFM,

To maintain the Absolute Local Time implementing a synchronisation process without convergence (see section A.7),

To send on request the current Absolute Local Time towards the slave Module Clock CFMs,

To send the start time message to a CFM with a slave MC, after receipt of readiness status message from that CFM,

To send on request the couple of values: stored AGT0/ALT0,



A.5.1.6. RTBP data For the Reference Clock CFM the following data have to be defined in the RTBP:

The RC identifier,

The structure for the slave MC CFMs (list of CFM_id and MC_id),

The synchronisation wave rate (frequency or period) for triggering the ALT requests to the MRC,

The maximum bound for the time difference between the parent and the slave clock (MaxALTDiff),

The ALT resolution bound that ensures the ALT resolution to be achieved between all the CFMs and the MRC (ALTResBound), This bound is related to the system ALT resolution and the topology between the considered slave clock (RC or MC) CFM and the MRC CFM. A unique value can be considered when the minimum ALTResBound is applied to all the transmission path between two individual CFMs,

The parent MRC CFM identifier (CFM_id).

A.1.19 Module Clock CFMs A.5.1.7. Initialisation/Configuration The modules holding a Module Clock are determined by ASAAC system concept. These are the SPMs, DPMs, GPMs and PCMs.

Each of them needs the knowledge of the parent RC CFM required by the time service initialisation.

The initialisation of the MCs requires locally the following sequence:




To send the request to the RC for getting for the first time the current RC ALT,

To start and initialise the ALT counter with the current RC ALT time value,

NATO UNCLASSIFIED

25

NATO UNCLASSIFIED


To send the request to the RC for getting the couple of time values (AGT0/ALT0),

To store locally the couple AGT0/ALT0,

To send to the parent RC a readiness status for the ALT synchronisation process.

A.5.1.8. Functionality At the nominal state, each MC CFM shall provide the following functionality:

To maintain the Relative Local Time,

To send (periodically) a request to the parent RC for getting the Absolute Local Time reference,

To receive the Absolute Local Time from the parent Reference Clock CFM,

To maintain the Absolute Local Time implementing a synchronisation process without convergence (see section A.7),



A.5.1.9. RTBP data For the Module Clock CFMs the following data have to be defined in the RTBP:

The MC identifier,

The synchronisation wave rate (frequency or period) for triggering the ALT requests to the parent RC,

The maximum bound for the time difference between the parent and the slave clock (MaxALTDiff),

The ALT resolution bound that ensures the ALT resolution to be achieved between all the CFMs and the MRC (ALTResBound), This bound is related to the system ALT resolution and the topology between the considered slave clock (RC or MC) CFM and the MRC CFM. A unique value can be considered when the minimum ALTResBound is applied to all the transmission path between two individual CFMs,

The parent RC CFM identifier (CFM_id).

A.1.20 Reset of the ALT/RLT The following table provides the different possibilities for the reset of the ALT and the RLT.

Table A.1 - Reset cases for the RLT and ALT

Reset type RLT ALT

Power on Yes Yes

Hard reset Yes Yes

Soft reset No Yes

Watchdog reset No No

NATO UNCLASSIFIED

26

NATO UNCLASSIFIED


A.6. RTBP requirement summary

The following table summarises the identified data to be available in the RunTime Blueprint. Three sets are identified according to the type of clock.

Table A.2 - RTBP Time mgt data summary table

RTBP Data MRC CFM RC CFMs MC CFMs

MRC tag Yes No No

RC identifier RC_id RC_id N/A

MC identifier N/A N/A MC_id

Structure for the slave CFMs List of RC CFM_id

List of MC CFM_id

List of MC CFM_id N/A

Parent CFM identifier None MRC CFM_id RC CFM_id

Clock synchronisation wave period 3

SyncWavePeriod SyncWavePeriod SyncWavePeriod

Maximum number of allowed consecutively missing messages 3

N/A MaxOfMissedALT MaxOfMissedALT

Acceptable range for the received ALT reference values 3

N/A RangeforALT RangeforALT

Maximum bound for ALT time value difference

N/A MaxALTDiff MaxALTDiff

ALT resolution bound N/A ALTResBound ALTResBound

A.7. ALT synchronisation algorithm

A.1.21 Specification – nominal case The Absolute Local Time synchronisation algorithm is based on:

The propagation delay estimation at every synchronisation wave period in order to provide the slave clock with the estimation of the Parent ALT at reception of the ALT request reply message,

The difference of the ALT time values between a parent clock and a slave clock,

The status of the slave clock (beyond maximum bound, beyond ALT resolution, synchronised),

The rate of the difference of the clock speeds,

The linear correction to apply to the slave ALT during the next synchronisation wave period.

3 See section A.7.

NATO UNCLASSIFIED

27

NATO UNCLASSIFIED


Parent Clock(MRC or RC)

Federated Clock(RC or MC)

N

N+1

TPar(t1)

TPar(t2)

TFed(t0)

TFed(t1)

TFed(t2)

requestALT()

sendALT()

SyncWavePeriod

requestALT()

sendALT()

2∗∆N = t2 - t0

TPar(t2) = TPar(t1) + ∆N

One waytransmission delay: ∆N

∆N

∆N

2∗∆N+1

Parent ALT estimation:

Corresponding federatedALT:

TFed(t2)

Figure A.3 - Estimation of the Parent Clock time value

The propagation delay is provided by the duration of the request-reply made by the slave clock CFM using its RLT (denoted by ti). Assumption is made that the delay is the same for the go and return path.

The difference of ALT time values is then given by:

∆NT = TFedN(t2) – TParN(t2)

∆NT = TFedN(t2) – TparN(t1) - ∆N

The slave clock is in advance when ∆NT > 0 and late when ∆NT < 0.

The status of the slave clock: Beyond maximum bound, Beyond ALT resolution bound or Synchronised is determined with a check of the difference of the ALT time values with these ceilings:

Beyond maximum bound:|∆NT| > MaxALTDiff,

Beyond ALT resolution bound:ALTResBound < |∆NT| ≤ MaxALTDiff,

Synchronised: |∆NT| ≤ ALTResBound.

When synchronised no correction to the slave ALT is applied. For the two other cases a linear correction is applied to the slave ALT during the incoming synchronisation wave period using a clock speed rate factor αN (see Figure A.4).

αN = 1 - ∆NT/SyncWavePeriod

The update of the local time is provided by reference to the last record of the ALT as shown in figure below.

NATO UNCLASSIFIED

28

NATO UNCLASSIFIED


x

Federated ALTN(x) = Federated ALTN + x . ∆NT SynchWave period

1 -

αN

N N+1

FederatedALT

FederatedALT(x)

SynchWaveperiod

time

αN

∆NTSynchWave period -

∆NT > 0 : Federated ALT in advance / Parent∆NT < 0 : Federated ALT late / Parent

Figure A.4 - Update of the local ALT

A.1.22 Difference of ALT time value Beyond maximum bound In such a case an error is raised to the GSM Health Monitor in order to decide how to manage this CFM that at that moment does not provide the system with ALT synchronisation.

A.1.23 Altered or missed received ALT reference A range of acceptable received ALT reference value and a maximum number of consecutively missing or discarded received ALT have to be specified and implemented in the algorithm.

When the ALT is received outside these ranges an error is raised to the GSM Health Monitor otherwise the algorithm is applied. When an error is raised the algorithm (SynchroniseALT( ) service) shall not be activated and thus the received altered ALT value shall not be taken into account.

A.1.24 The parameters to use Three parameters are identified being important for the algorithm:

SyncWavePeriod,

MaxALTDiff,

ALTResBound.

These parameters will be determined and recorded into the RTBP.

NATO UNCLASSIFIED

29

NATO UNCLASSIFIED


A.1.25 ALTResBound Since the ASAAC Stage 1 architecture synthesis document have specified clock resolutions for the AGT, ALT and RLT, the performance requirements are known not being achievable by the current design that is used for the VME-CPP, IMA-CPP and CCPP.

The specified resolution for the AGT to the RLT is reminded in the following summary table.

Table A.3 - Time types and resolution (requirement)

Type Resolution Roll over

Absolute Global Time 1 to 10 ms > 60 days

Absolute Local Time 1 µs to 0.1 ms Daily

Relative Local Time < 1 µs > 60 seconds

The accuracy of the clocks should be much higher than the resolution being in the range of +/- 0.01% =>>> Better: The accuracy of the timers shall be 1/10 or less of the resolution.

The characteristics to use for the demonstrations have to be as close as possible of these requirements.

The ALTResBound shall be determined using the ‘expected’ ALT resolution and the maximum transmission path in the clock hierarchy. Assumed to be 2 (MRC -> RC and then RC-> MC).

So that ALTResBound = Expected ALT resolution / 2.

The expected resolution for the ALT can be 50 µs. That leads to a ALTResBound of 25 µs.

A.1.26 SyncWavePeriod An estimation of the possible performance using the following equation determines the maximum bound for the SyncWavePeriod.

T ≤ [ |MI.(1-ρ)| + |j| ] /ρ

Using the following figures:

Jitter max j = 10 µs

Clock drift rate ρ = 0.001%

MI = ALTResBound = 25 µs

That leads to a SyncWavePeriod ≤ 3.5 sec. Let us take 1 second.

A.1.27 MaxALTDiff, The MaxALTDiff shall be four times the ALTResBound so that leads to MaxALTDiff = 100 µs.

NATO UNCLASSIFIED

30

NATO UNCLASSIFIED


(informative)

Clock synchronisation methods with convergence functions

B.4. Foreword

This annex provides a summary of documentary research and study for information only.

B.5. References

1. RFC 956 Algorithms for synchronising Network Clocks.

2. Technique et Science Informatique Vol13, N2 / 1994 – “Modélisation des techniques de synchronisation d’horloges” - Jiying He, Zoubir Mammeri, Jean-Pierre Thomesse.

3. Proc. Advanced Seminar Real Time Local Area Network, Bandol (France) 1986 – “A paradigm for reliable clock synchronization” – Schneider F.B.

4. ACM T.O.P.L.A.S. vol6 n°2 Apr.1984 - “The Byzantine generals problem” Lamport L., Pease M., Shostak R.

5. JACM vol 32 n°1 Jan. 1985 – “Synchronizing clock in the presence of faults” - Lamport L., Melliar-Smith P.M.

B.6. Clock Synchronisation

Clock synchronisation allows, despite skews of the physical clocks from the different sites, the ability to maintain a common system (global) time of which the values (time) over the system are approximately equivalent i.e. within the system time resolution. The properties of time delivered by such clock are provided in Annex A.

B.6.1. Principles and Approaches for Clock Synchronisation The clock synchronisation consists in adjusting local clocks over different sites of a system such as:

1. The skew between two Synchronised Clocks is maximum bounded and,

2. The maximum drift rate of a Synchronised Clock (against time reference) is also maximum bounded.

B.6.1.1. Elementary functions for clock synchronisation The analysis of the principle and later the design approaches is facilitated by giving a simple decomposition of the clock synchronisation function.

NATO UNCLASSIFIED

31

NATO UNCLASSIFIED


ReferenceAt tR

DeviationAt tD

AdjustingAt tA

Reference values

R(t)

AdjustingInstants

tA

Adjustingdata A(t)

SynchronisedClockTime SC(t)

Figure B.5 - Clock Synchronisation functions

As shown in Figure B.5 three elementary functions participate to the overall function. They are:

The “Reference” function that plays a double role. First it provides the reference value R(t) to be used to compute the Adjusting function and it also determines the adjusting triggering instant tA. There are as many R(t) and tA as sites in the system,

The “Deviation” function that consists in generating in accordance with the reference value(s) the local adjusting data D(t). The deviation is the difference between the time reference and the local clock time. There are as many D(t) as sites in the system,

The “Adjusting” function that consists in modifying at the adjusting triggering instant, the local clock time using the local adjusting data in each site.

The algorithm or mechanism used for the clock synchronisation function is usually triggered periodically. The synchronisation wave is defined being between two consecutive clock synchronisation triggering instants (the period) and the synchronisation duration is the execution time.

B.6.1.2. Design approaches for clock synchronisation Three approaches are possible, the centralised one, the decentralised one and mixed approach that is based on the two previous ones. Obviously distributed systems are concerned and all the approaches are matching the requirement for a distributed system. One introduces the term privileged site or master site in the case of a computation performed only one time on one site for the benefit of the others. The receiving sites are called slave sites

In the centralised approach, the reference values are computed by only one site (the privileged) among all the system sites. The deviation function can either be locally performed by each site for its own usage in a case of a partially centralised structure, or be performed by the master site, the structure is then called a totally centralised structure.

This approach to be fault tolerant requires the special techniques like redundancy of the master site or election algorithms. The communication cost is the lowest.

The decentralised approach implements a duplication of the same synchronisation function into all the distributed sites. This approach is intrinsically fault tolerant but its communication cost is greater than the centralised approach one.

The mixed approach implements a decomposition of all the sites into groups. For each group there is a privileged site and slave sites. For the whole system, the clocks of the master sites are generally synchronised on the basis of a decentralised implementation. For each groups the slaves sites can be

NATO UNCLASSIFIED

32

NATO UNCLASSIFIED


synchronised on the basis of the centralised approach. The mixed approach is a compromised between fault tolerance and communication cost.

The implementation for clock synchronisation can be hardware solution, software solution or an hybrid solution that incorporate a mixed of the two firsts.

Hardware solutions use dedicated circuits and buses that provide better accuracy (clock skew) than software solution. However the cost is high and they are only retained for high quality time accuracy.

Software implementation uses exchange of message between the system sites via a communication network. These solutions are flexible and cheaper than hardware solutions but necessitate bus bandwidth and messages that decrease the time accuracy.

Hybrid solutions aim to increase software solutions accuracy and reduce the cost of hardware equipment.

B.6.2. Performance Criteria In order to analyse the performance of a solution for clock synchronisation the following commonly adopted criteria have to be assessed:

The synchronised clock skew δ,

The drift rate ρ,

The communication cost (number of messages that are necessary for the clock synchronisation function),

The fault tolerance degree.

The synchronised clock skew and the drift rates are quality criteria for the resultant clock time obtained by the synchronisation function. These criteria are determined by the application (user) requirement.

The communication cost allows to identify the bandwidth and load of the communication channels that are dedicated to clock synchronisation.

The fault tolerance criterion represents the capability for a clock synchronisation algorithm to continue to provide a correct global time while a number of sequential faults occurred. Often higher is the tolerated fault number higher is the number of messages.

It is obvious that the importance given to such criterion is related to the need of the application that uses the system time reference.

B.6.3. Fault tolerance The exchange of messages in a synchronisation wave are subject to fault occurrences. Every site has to provide against corrupted values and the lost of them. The solution is to include fault tolerance mechanisms in the clock synchronisation algorithms.

B.6.3.1. Types of faults For a site that receive messages containing clock value, faults can be grouped as follows:

Temporal faults: clock messages are not received or transmitted on time,

Non arbitrary faults on the value: a same clock value is broadcast to all the sites. But when received, the clock value is judged incorrect because the clock of the transmitter site is faulty,

Arbitrary faults or Byzantine: The operation on the transmitter clock process or on the transmitted site or on the network is such as the reception sites do not receive the same clock value from one clock broadcast to all the other sites at the same time.

NATO UNCLASSIFIED

33

NATO UNCLASSIFIED


Temporal faults detection can easily be recovered using time switches. The detection of erroneous values is more complex and necessitates the use of special mechanisms. Non arbitrary faults on the values are detected by the use of rejection mechanisms and Byzantine faults are handled by tuning protocols.

B.6.3.2. Tolerance of Non Arbitrary faults on the values In order to limit the impact of such faults, every site has to reject the values that are judged incorrect. There are two main techniques to achieve that:

The egocentric rejection that is based on the assessment against a ceiling of the time difference between the received value with the local clock value. This technique is used only under the condition that the local clock is assumed reliable,

The rejection of the extreme values that is based after the sorting of all the received values on fixing a number of rejected values both among the highest and the lowest (in some techniques the number of rejected values can be the degree of fault tolerance and it is a priori fixed according to the maximum number of faults to tolerate).

B.6.3.3. Byzantine Fault tolerance The issue of Byzantine faults in clock synchronisation is a specific case of the Byzantine generals problem that is how for distributed processes that elaborates a correct and identical global view of a global state from their respective local view of this state despite failures for some of them (processes).

The first algorithms were established by Lamport (ref 4) that are the tuning protocols:

Oral Message (OM). OM is a recursive algorithm that necessitates nm+1 messages to tolerate m faults Byzantine (n is always greater or equal to 3m+1),

Signed Message (SM). SM necessitates a mechanism of signed messages by their transmitters.

In decentralised systems specific conditions have to be followed to compute the reference value (cf. 5):

The tuning condition: All the safe sites approximately agree on the value of a site k, even if it has failed,

The validity condition: whether a site k is safe, all the other safe sites approximately get the current clock value of the site k.

Furthermore the solution provided by Tuning protocol such as OM and SM assumes that the values contained into the messages are static (no evolution with time). This is not the case of physical clock values (ideally transmitted clock value should evolve during the transfer but is not feasible!). This new problem was addressed by Lamport (ref. 5) that has expanded the Tuning Protocols to fully comply with clock synchronisation characteristics. They are called Clock Oral Message and Clock Signed Message.

B.7. Algorithm class overview

This section aims to present an overview of the groups of algorithms that are available to perform the three elementary functions required for clock synchronisation implemented by software solution (from time concept).

Let’s defined some further notations useful for the following:

Site k is the distant site,

Site i is the site where a function computation requires the distant site data,

Ck(t) is the physical clock time read at time t by the distant site k,

NATO UNCLASSIFIED

34

NATO UNCLASSIFIED


Cik(t) is the site i physical clock time estimate of the distant site k physical clock time computed at time t in site i,

SCk(t) is the synchronised clock time read at time t by the distant site k,

SCik(t) is the site i synchronised clock time estimate of the distant site k synchronised clock time computed at time t in site i,

tk is the clock reading instant by the site k,

tik is the site i estimate of the clock reading instant by the site k.

The design approach have to be known and in principle the distinction between a centralised or a decentralised approach has to be identified.

B.7.1. Reference function B.7.1.1. Generalities For the reference function computation the type of convergence for site convergence has to be identified. A convergence function (denoted F in the following) is implemented for the computation of the reference values and the adjusting triggering instants. It depends of the combination for the computing of these two outputs that can be either global or local computation.

A global computation requires inter-sites communication to uses distant sites clock times whereas a local computation only uses the local site data. The global computation raises the issue of remote clock reading.

A convergence function can be:

A value convergence type function that provides a global computation for the reference values and a local computation for the adjusting instants,

An instant convergence type function that provides a local computation for the reference values and a global computation for the adjusting instants,

A value and instant convergence type function that provides a global computation for both the reference values and the adjusting instants.

The following table summarises the possible combinations for the convergence function.

Table B.2 - Reference function convergence types

Reference value

Global Local

Adjusting instant Global Value & Instant convergence

Instant convergence

Local Value convergence No convergence

Note that local computations for both the reference values and the adjusting instants will be called synchronisation without convergence. The rest of this section deals with clock synchronisation with convergence.

The kind of arguments the convergence function uses has to be known among:

NATO UNCLASSIFIED

35

NATO UNCLASSIFIED


the physical clock time ,

the synchronised clock time,

the difference of physical clock times,

Wik(t) = Cik(t) – Ci(t) is the difference between the site i physical clock time estimate of the distant site k physical clock time and the local site i physical clock time read at time t,

the difference of synchronised clock times.

SWik(t) = SCik(t) – SCi(t) is the difference between the site i synchronised clock time estimate of the distant site k synchronised clock time and the local site i synchronised clock time read at time t,

For global computation of the reference value the remote clock reading techniques have to be detailed. They can be determinist, probabilistic or statistical. Whatever the technique is, it is based upon one of the two following principles:

Message based principle in which the remote site (site k) provide its clock time (Ck(tk) or SCk(tk)) by sending a message to the site that needs this data (site i) or,

Remote reading instant estimate principle in which the site i has to know by the use of special techniques (statistical techniques) an instant tik that is a good estimate of the remote clock reading instant tk.

The Message based principle in their determinist techniques can involve reading mechanisms with reading request or without request.

Associated to the remote reading issue is the implementation of specific fault tolerance protocol to discard ‘bad’ clock values, to accept that certain sites do not transmit their time and to accept that some messages being lost or altered during transmission.

Another aspect that impact the different techniques is the assumptions that can be made on the communication latency. According to the selected network the maximum bound for communication latency cannot be known. When in fact, the accuracy for synchronised clock when determinist and probabilistic techniques are used is related to the knowledge of the minimum and maximum boundaries. Statistical techniques only require the minimum latency bound:

∆min ≤ ∆ik

For determinist and probabilistic techniques ∆max is required and the following two categories of assumptions are made:

Assumption 1: There are one maximum bound and one minimum bound for all the couples of sites i,k (1≤ i ≤N ; 1≤ k ≤N). So that

1≤ i ≤N ; 1≤ k ≤N ; st ∆min ≤ ∆ik ≤ ∆max

Assumption 2: There are one maximum bound for all the couples of sites i,k and a dedicated minimum bound for each the couples of sites i,k and for each communication path.

1≤ i ≤N ; 1≤ k ≤N ; st ∆ik ≤ ∆max

∆mini->k ≤ ∆i->k

∆mink->I ≤ ∆k->i

According to the following notations:

NATO UNCLASSIFIED

36

NATO UNCLASSIFIED


∆i->k is the communication latency between the site i and k, following the communication path from site i to site k,

∆k->i is the communication latency between the site k and i, following the communication path from site k to site i,

∆ik is the communication latency between the site i and k, whatever is the communication path,

∆mini->k is the minimum bound for communication latency between the site i and k, following the communication path from site i to site k,

∆mink->i is the minimum bound for communication latency between the site k and i, following the communication path from site k to site i,

∆min is the minimum bound for communication latency for all couples of sites, whatever is the communication path,

∆max is the maximum bound for communication latency for all couples of sites, whatever is the communication path.

The following table summarises the remote clock techniques according to the assumption made on the latency bounds.

Table B.3 - Remote clock techniques and latency bounds

Determinist Probabilistic Statistiques

Assumption 1 & Assumption 2 ∆min ≤ ∆ik

∆max is known for all communication paths

If ∆ik ≥ ∆max there is a reading lost.

∆max is arbitrarily fixed for all communication paths

A probability p is defined so that there is:

Proba p for ∆ik ≥ ∆max

Proba 1-p for ∆ik < ∆max

A site i can attempt r reading so that the success clock reading as a proba (1 – p)r

If ∆ik ≥ ∆max there is an attempt failure

For global computation of the adjusting Instant the type of techniques used for the adjusting instant computation has to be known. It can be based upon:

Digital signature technique that consists in coding or sign transmitted message in order to avoid erroneous messages or relaying dysfunction,

Mean of the receiving times technique,

NATO UNCLASSIFIED

37

NATO UNCLASSIFIED


Centralised broadcasting technique that is dedicated to centralised structures only,

Synchronous technique.

B.7.1.2. Reference Function and Design Structures A local computation for both the reference value and the adjusting instant has no relationship with the adopted Design structure for the clock synchronisation function. Furthermore a global computation using the differences of clock values is equivalent to using the clock values themselves. So the only interest is to state about the global computing for the convergence function parameters.

B.7.1.2.1. Reference function in a decentralised structure

Computation of the reference values When the reference value is computed by each site using the whole system clock values (global computing) the model for the convergence function in the site i is as follows:

1≤ k ≤N Ri(tRi) = F[SCi1(tRi) , SCi2(tRi) … SCiN(tRi)]

where tRi is the instant for the computation of the reference value in site i

SCik(tRi) is the site i estimate of the site k clock time (synchronised clock)

F is the convergence function

Note that at this stage Physical Clocks can replace the Synchronised Clocks.

11 22 NNkksitesite

tR1tR2

tRk

tRN

R1(tR1) R2(tR2)

Rk(tRk)

RN(tRN)

R1(tR) R2(tR) Rk(tR) RN(tR)tR

Figure B.6 - Reference values in a decentralised structure

There are as many tRi as sites in the system and thus there is an inconsistency issue between all the reference values computed locally in each site. In order to get a convergence degree for the reference values, it is necessary for them to be values of a same real instant. This instant is denoted tR that corresponds to the maximum of the site i computing instants.

tR = max { tRk ; 1≤ k ≤N }

The inconsistency between the reference values is measured by the reference accuracy π.

π = max { |Rj(tR) – Rk(tR)| ; 1≤ j ≤N , 1≤ k ≤N }

NATO UNCLASSIFIED

38

NATO UNCLASSIFIED


Convergence function and clock reading In the decentralised structure the whole clock values used to compute the reference value, during a synchronisation wave, vary from one site to another. The argument of the convergence function has to comply with the following two conditions:

The time period allocated to a considered site for performing the remote clocks reading of the other sites shall be the smallest.

In order to get all the sites having approximately the same clock value of the considered site i, it is necessary that the other sites performed their remote clock reading of the site i within a time period that also has to be the smallest (one notices that this condition is implicitly fulfilled whether each site periodically broadcast their clock value).

To summarise, that means that the remote clocks reading between all the sites has to be limited within a small time period.

Whether Θ denoting the maximum bound for the differences between all the couples of clock values used in the convergence function in one site and Φ denoting the maximum bound for the difference between the clock values corresponding to a same site used by the other sites, the convergence function has the following property.

Accuracy Property for the convergence function (demonstrated by Schneider in 3)

1≤ i ≤N ; 1≤ k ≤N

| F[SCi1(tRi), …, SCiN(tRi)] - F[SCk1(tRk), …, SCkN(tRk)] ≤ π (Θ , Φ)

where

Θ ≥ max { |SCip(tRi) – SCiq(tRi)| ; 1≤ i ≤N ; 1≤ p ≤N ; 1≤ q ≤N }

Φ ≥ max { |SCip – SCkp| ; 1≤ i ≤N ; 1≤ k ≤N ; 1≤ p ≤N }

This property means that the differences between reference values computed by the various sites during a same synchronisation wave have to be bounded.

Notice that only synchronised clock values are used. This is because the difference between two physical clocks cannot be bounded. Actually physical clocks are not affected by the synchronisation process in a software implementation.

As a consequence both the computation for the reference values and the adjusting instants in a decentralised structure have to use the synchronised clock values as argument.

Computation of the adjusting instant Either the reference value is computed locally and the adjusting instant has to be determined by a global manner or the reference value is computed globally and the adjusting instant can be determined by a global or local manner.

With the following notation:

Tj is the adjusting instant of the synchronisation wave j,

T0 is the first adjusting instant.

The theoretical model for the adjusting instant computation is

Tj = T0 + j*V

NATO UNCLASSIFIED

39

NATO UNCLASSIFIED


Where

j is the jth synchronisation wave

V is the period for a synchronisation wave.

iisitesite

T0

V

Tj

T1

V

σ

Figure B.7 - Adjusting Instant computation principle

σ is the dispersion of the adjusting instant.

With the exception of the centralised broadcasting technique all the ones identified in section B.7.1.1 are possible.

B.7.1.2.2. Reference function in a centralised structure

In centralised approach the privileged site plays a particular role as follows:

It supplies the reference values for the whole sites or,

it determines the adjusting instants for the whole sites or,

it supplies both the reference values and the adjusting instants for the whole sites.

B.7.1.2.3. Reference function in a centralised structure

Two possible ways for the privileged site (site p) to determine the reference value:

by using the privileged site local clock value (totally centralised structure) that leads to the following equation

Rp(tRp) = Cp(tRp)

or

Rp(tRp) = SCp(tRp)

by using all the system site clock values (partially centralised structure). In that case a convergence function is required such as:

Rp(tRp) = F[Cp1(tRp), … , CpN(tRp)

or

NATO UNCLASSIFIED

40

NATO UNCLASSIFIED


Rp(tRp) = F[SCp1(tRp), … , SCpN(tRp)

In the partially centralised structure only the clock values are used since in a totally centralised structure the difference between clock values can also be used.

Because the clock values transmitted by slave sites are received by a unique site (the privilege site p) the Byzantine faults cannot occur.

B.7.2. Deviation function The characteristics of the Deviation function depend on the type of techniques used for the computation of the Reference function. Indeed, whether the adjusting data are obtained from a global computation of the reference value, approximations are introduced and transmitted to the adjusting data or whether the reference value is obtained from local computation, there is no approximation and no error on the computation of the adjusting data. The synchronised clock time accuracy depends only to the dismissal factor on the adjusting instants.

The function is defined by:

R(t)tR

D(tR):

iisitesite

Ri(tR) tR

Di(tDi) tDi

Figure B.8 - Deviation function principle

With the following notations:

Di is the adjusting data computed by the site i,

tDi is the instant at which the adjusting data are computed by the site i.

The theoretical models for computing the adjusting data when based on clock values are as follows:

Di(tDi) = Ri(tDi) – Ci(tDi)

or

Di(tDi) = Ri(tDi) – SCi(tDi)

Practically, only approximate computation for the adjusting data are provided. There are denoted:

Di’ is the approximate adjusting data computed by the site i,

B.7.2.1. Deviation function in a decentralised structure In decentralised structure the site i computes its adjusting data by one of the following equations

NATO UNCLASSIFIED

41

NATO UNCLASSIFIED


Di’(tDi) = Ri(tRi) - SCi(tDi) clock value based

Or Di’(tDi) = Ri(tRi) clock value difference based

Where: tDi is the computation time of Di’

B.7.2.2. Deviation function in a centralised structure B.7.2.2.1. Deviation function in a totally centralised structure

In totally centralised structure the privileged site p computes the adjusting data for every site i by one of the following equations:

Di’(tDi) = Rp(tRp) - Cpi(tDp) physical clock value based

Di’(tDi) = Rp(tRp) - SCpi(tDp) synchronised clock value based

or Di’(tDi) = F[Wp1(tRp),…,WpN(tRp)] - Wpi(tRp)

phy. clock value difference based

Di’(tDi) = F[SWp1(tRp),…,SWpN(tRp)] - SWpi(tRp)

synch. clock value difference based


The privileged site p computes its adjusting data Dp’(tDp) by either:

• replacing Cpi(tDp) by Cp (tDp) (respectively SCpi(tDp) by SCp (tDp)) when the two first functions are used

or

• Wpi(tDp) by 0 (respectively SWpi(tDp) by 0) when the two last are used.

B.7.2.2.2. Deviation function in a partially centralised structure

In partially centralised structure the reference value obtained by the slave site is a similar problem as for obtaining the remote clock values reading.

Because the slave sites do not know when the privileged site has produced the reference value the simplest mechanism for it is to broadcast (without request) this value when it is available in the privileged site p.

If Byzantine faults have to be tackled, tuning protocols have to be implemented (cf. B.6.3.3).

Each slave site i computes its adjusting data by one of the following equations:

Di’(tDi) = Rp(tRp) + αi - Cpi(tDi) physical clock value based

Di’(tDi) = Rp(tRp) + αi - SCpi(tDi) synchronised clock value based


αI is the interval length between the instant where the privileged site has finished to compute Ri and the reception of this value by the site i.

NATO UNCLASSIFIED

42

NATO UNCLASSIFIED


If the privileged site transmits Ri immediately after its computation and if no tuning protocol is used αI can be replaced by the communication mean latency τ.

The privileged site computes is adjusting data by one of the following equations:

Dp’(tDp) = Rp(tRp) - Cp(tDp) physical clock value based

Dp’(tDp) = Rp(tRp) - SCp(tDp) synchronised clock value based

B.7.2.3. Deviation error and adjusting bound The deviation error is defined as being the difference between the approximate adjusting data and the theoretical data:

Deviation error = Di’(tDi) - Di (tDi)

In each synchronisation wave for one site, the adjusting data determines a quantity to add or remove to the synchronised clock. The maximum bound for these value is called the adjusting bound.

The adjusting bound determines how far is the synchronised clock from the physical clock for a same site. If the adjusting bound is very small in comparison to the synchronisation wave length, that means that the synchronisation clock provide a good approximation of the time reference.

B.7.3. Adjusting function Finally the mode for the Adjusting function has to be selected. It can be:

the discontinuous adjustment technique that consists in adjusting the local clock only one time during the synchronisation wave. In the case of software solution the condition P2 is not ensured because in that case the frequency or the physical clock cannot be modified. So this solution is applicable when hardware or hybrid solutions are implemented,

The expanded adjustment technique also called pseudo-continuous adjustment technique that consists in adjusting the synchronised clock by a quantity (denoted Qj) that depends on both the adjusting data and the synchronisation wave length.

Only the expanded adjustment is relevant for this analysis.

B.7.3.1. expanded adjustment In practice the expanded adjustment is carried out when a reading request is used (the alternative could be to synchronise the technique with the physical clock tick).

After the adjusting function the adjusting instant tAi takes the value t.

NATO UNCLASSIFIED

43

NATO UNCLASSIFIED


iisitesite

tAji

tSynWinitj

t

tAj+1i

tSynWinitj+1

t

V

Figure B.9 - Adjusting function principle

Whether the adjusting data is obtained by the physical clock values or the difference of physical clock values, the adjustment is realised by the following equation and notations:

j denotes the synchronisation wave,

i denotes the site,

tSynWinitj is the start time for the synchronisation wave j.

SCji(t) = Cj

i(t) + [Cji(tDj

i)-Cji(tSynWinitj)]*Aj

i’(tAji)/V + [Cj

i(t)-Cji(tDj

i)]*Aji’(tAj

i)/V

The middle term denotes the sum of the quantities (Q) used in the previous synchronous waves. It can be expressed as follows:

Yj(tDji) = [Cj

i(tDji)-Cj

i(tSynWinitj)]*Aji’(tAj

i)/V

The first equation can be simplified to lead to:

SCji(t) = Cj

i(t) + [Cji(t)-Cj

i(tSynWinitj)]*Aji’(tAj

i)/V

Whether the adjusting data is obtained by the synchronised clock values or the difference of synchronised clock values, the adjustment is realised by the following equation:

SCji(t) = [SCj

i(tDji) + Cj

i(t) - Cji(tDj

i)]+ [Cji(t)-Cj

i(tDji)]*Aj

i’(tAji)/V

As for the continuous adjustment the initial value of the synchronised clock is fixed to tSynWinit0 or T0

To ensure the chronoscopic timing feature to the synchronised clock the use of the expanded technique is required but not sufficient. Indeed when the adjusting data is less than –V, the backward of the synchronised clock is unavoidable.

NATO UNCLASSIFIED

44

NATO UNCLASSIFIED


(Informative)

Time definitions and properties

Foreword

This annex provides a summary of documentary research and study for information only.

Physical Time and Properties

Physical time The time used within a system is the physical time. The physical time is defined as being a measurable time. It is generally provided by Clocks. This time is usually compared to reference time (e.g. UTC) to quantify real time system (we also called it real time in the rest of this annex).

In small caps, t denotes the real time (e.g. the system time reference).

Minimal Interval of a system Whatever is the system, it exists a Minimal Interval (MI) that depicts the minimal time quantity that can separate two event occurrences. If the interval between two events is smaller than MI the two events are considered appearing simultaneously.

The Minimal Interval is related to the accuracy of timing of events within the system.

Physical Time Properties To be used within a system the physical time shall comply with three constraints that are usually called properties of the physical time:

P1. If the time that separates two events is higher than system Minimal Interval (MI), the physical time shall allow the distinction with no ambiguity of those two events that have not appeared simultaneously.

P2. The physical time shall provide chronoscopic timing (i.e. If an event A appears before an event B, the timing allocated to event A shall be lower than the timing allocated to event B).

P3. If an event A appears before an event B, the time difference computed from the allocated timing between A and B shall be approximately comparable to the elapsed time between the apparition of the two supporting events.

Physical Clocks and Synchronised Clocks

Both provide a physical time thus a time used by the system. The Synchronised Clock is a Physical Clock on which synchronisation algorithms are applied to provide the system with a (almost) synchronised time to a time reference. Both hardware and software synchronisation are available.

Physical Clock Properties Let’s define the physical clock time T supplied by the physical clock i as a function of the real time t:

T = Ci(t)

and its reverse function that characterises the real time as which the clock i tells time T:

t = ci(T)

NATO UNCLASSIFIED

45

NATO UNCLASSIFIED


It is important to distinguish clock time and reference time (real time)

Physical clocks have to comply with the following property:

P4. The Accuracy property states that Physical Clocks have to stay within a linear envelope of the time reference.

∃ χ << 1 st 1-χ ≤ [C(t2) – C(t1)] / (t2-t1) ≤ 1+χ with t2=t1+∆t

where χ is the maximum drift rate of the Physical Clock vs the real time.

∆t is the clock resolution.

The drift rate is the rate at which the clock can gain or loose time. The smaller it is the longer it keeps the time within a linear envelope of the time reference.

The maximum drift rate between two clocks located on two different sites is thus equals to 2χ.

Synchronised Clocks Properties The clocks of the system have first to satisfy the three properties of the physical time (i.e. P1, P2, P3).

Let’s defined the physical clock time T supplied by the physical synchronised clock i as a function of the real time t:

T = SCi(t)

and its reverse function that characterise the real time as which the synchronised clock i tells time T:

t = sci(T)

To be qualified as synchronised clocks, two clocks have to satisfy two additional properties.

P5. The tuning property that states that the difference between two clocks from different sites (i and j) shall be bounded.

This is expressed by the following relation.

1≤ i ≤N ; 1≤ k ≤N; δ>0 st |Ci(t) – Ck(t)| ≤ δ

where δ is the maximum allowed skew between the synchronised clocks.

This property can also be expressed at physical time by an equivalent equation.

P5 is not sufficient for having a time provided by synchronised clock in conformity with the time reference. A second property, the accuracy property has to be satisfied.

P6. The accuracy property for Synchronised Clocks is derived from the accuracy property for Physical Clocks (P4). It states that the Synchronised Clocks have to stay within a linear envelope of the time reference.

This is expressed by the following relation.

NATO UNCLASSIFIED

46

NATO UNCLASSIFIED


NATO UNCLASSIFIED

47

∃ ρ << 1 st 1-ρ ≤ [Ci(t2) – Ci(t1)] / (t2-t1) ≤ 1+ρ with t2=t1+MI

where ρ is the maximum drift rate of the Synchronised Clock vs the real time.

MI is the system Minimum Interval.

The maximum drift rate between two Synchronised Clocks located on two different sites is thus equals to 2ρ.

As Synchronised Clocks differ one from another of at most the skew δ and have a drift against the time reference, so that the Minimum Interval (or resolution) of the system is minimum bounded.

P7. The Minimum Interval (or resolution) of the system is bounded. This bound is expressed by the following equation.

∃ MI st MI ≥ δ / (1-ρ)

This traduces that two events that have their occurrence instants separated by at least MI can be distinctly dated. In other words, the MI minimum bound is the maximum accuracy for event timing in the system.

NORTH ATLANTIC TREATY ORGANIZATION (NATO)read.pudn.com/downloads411/sourcecode/app/1750389/... ·...

Documents

Transcript of NORTH ATLANTIC TREATY ORGANIZATION (NATO)read.pudn.com/downloads411/sourcecode/app/1750389/... ·...