NORTH ATLANTIC TREATY ORGANIZATION (NATO)read.pudn.com/downloads411/sourcecode/app/1750389/... ·...
Transcript of 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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
NORTH ATLANTIC TREATY ORGANIZATION ORGANISATION DU TRAITE DE L’ATLANTIQUE NORD
MILITARY AGENCY FOR STANDARDIZATION (MAS) BUREAU MILITAIRE DE STANDARDISATION (BMS)
1110 BRUSSELS
Tel: 707.43.09
….. MAS …..
STANAG 4626 (DRAFT 1) – MODULAR AND OPEN AVIONICS ARCHITECTURES PART 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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
RESERVATIONS
RESERVES
NATO UNCLASSIFIED iv
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
AIM
1. The aim of this agreement is to define and standardize essential technical characteristics which shall be incorporated in the design of avionics architectures.
AGREEMENT
2. Participating nations agree to adopt the avionic architectures of future aircraft developments and upgrades to the Standards and Guidelines of open avionics architectures as described in this STANAG.
DEFINITIONS
3. The definition of terms and abbreviations used in this Agreement are given in each Part of the Standard.
GENERAL
4. t.b.d.
DETAILS OF AGREEMENT
5. The details of the agreement are given as follows:
• in Part I: Architecture Standard and Annex “Rationale Report for Architecture Standards”
• in Part II: Software and Annex “Rationale Report for Architecture Software Standards”
• in Part III: Common Functional Modules and Annex “Rationale Report for Common Functional Modules Standards”
• in Part IV: Packaging and Annex “Rationale Report for Packaging Standards”
• in Part V: Networks and Communication and Annex “Rationale Report for Communications / Network Standards”
• in Part VI: Guidelines for System Issues consisting of: • Vol. 1: System Management • Vol. 2: Fault Management • Vol. 3: System Initialisation and Shutdown • Vol. 4: System Configuration/Reconfiguration • Vol. 5: Time Management • Vol. 6: Security Aspects • Vol. 7: Safety
each Part being published separately as STANAG 4626 (Part I), STANAG 4626 (Part II), STANAG 4626 (Part III), STANAG 4626 (Part IV), STANAG 4626 (Part V) and STANAG 4626 (Part VI).
NATO UNCLASSIFIED 2
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
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 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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 11
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
• 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.
NATO UNCLASSIFIED 12
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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).
NATO UNCLASSIFIED 13
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED 14
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
Management Guidelines Volume 1 of this document, which presents the network management principle within a Core system
NATO UNCLASSIFIED 15
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 16
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 17
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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).
NATO UNCLASSIFIED 18
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
Figure A. 2 - Subsequent CFM initialisation (FS located on the AC MMM)
Figure A. 3 - Subsequent CFM initialisation (Remote Access)
NATO UNCLASSIFIED 19
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 20
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
A.1.3 CFM Shutdown and power down
Figure A. 5 - CFM shutdown
Figure A. 6 - CFM power off
NATO UNCLASSIFIED 21
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
A.1.4 Shutdown of an Integration Area
Figure A. 7 - Shutdown of an Integration Area
NATO UNCLASSIFIED 22
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
A.1.5 Shutdown of the Initial Configuration
Figure A. 8 - Shutdown of the Initial Configuration
NATO UNCLASSIFIED 23
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 24
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
MMM AC-GSM GSM_id = 99 IA Config_id = 141
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
RE Config_id = 14100
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.
MMM AC-GSM GSM_id = 99 IA Config_id = 400
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
RE Config_id = 40000
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
RE Config_id = 40000
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.
NATO UNCLASSIFIED 25
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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)
NATO UNCLASSIFIED 26
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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)
NATO UNCLASSIFIED 27
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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 for the ASAAC Programme are:
4. Reduced life cycle costs
5. Improved mission performance
6. 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 12 – ASAAC Standard Documentation Hierarchy
NATO UNCLASSIFIED 1
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
1.2 Document Structure
The document contains the following sections:
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
Normative ReferencesNormative References
Section 2
Terms & DefinitionsTerms & Definitions
Section 3
Configuration /ReconfigurationRequirements
Configuration /ReconfigurationRequirements
Section 4
Configuration /Reconfiguration
Concept
Configuration /Reconfiguration
Concept
Section 5
Definition forConfiguration
ReconfigurationStates & Modes
Definition forConfiguration
ReconfigurationStates & Modes
Links withSystem
Management
Links withSystem
Management
GSM logicalinterface
GSM logicalinterface
GSMconfiguration
GSMconfiguration
Configuration /Reconfiguration
Guidelines
Configuration /Reconfiguration
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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 document (7 volumes) provides System Issues guidelines supplementary to the Architecture Standard.
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
SMOS System Management to Operating System
RE Resource Element
TC Transfer Channel
VC Virtual Channel
NATO UNCLASSIFIED 6
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 10
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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,
NATO UNCLASSIFIED 11
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
- 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]),
NATO UNCLASSIFIED 12
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
- 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.
NATO UNCLASSIFIED 13
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 14
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 15
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED 16
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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:
NATO UNCLASSIFIED 17
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
- 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).
NATO UNCLASSIFIED 18
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 19
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 20
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 21
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED 22
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
NATO UNCLASSIFIED 23
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
NATO UNCLASSIFIED 24
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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,
NATO UNCLASSIFIED 25
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
- 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.
NATO UNCLASSIFIED 26
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
Configuration Loaded
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.
NATO UNCLASSIFIED 27
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
Configuration Loaded
RESuperord. AC / IA GSM
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.
NATO UNCLASSIFIED 28
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
Run Configuration
Activate All ConcernedApplications
Activate All ConcernedApplications
RunConfiguration
ConfigurationRunning
ConfigurationRunning
RESuperord. AC / IA GSM
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.
NATO UNCLASSIFIED 29
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
The acknowledgement for the stopping of the IA configuration is sent back to the super ordinate manager.
ConfigurationStopped
StopConfiguration
ConfigurationStopped
StopConfiguration
ConfigurationStopped
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.
NATO UNCLASSIFIED 30
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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.
ConfigurationRunning
RunConfiguration Run
Configuration
ConfigurationRunning
RunConfiguration
ConfigurationRunning
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.
NATO UNCLASSIFIED 31
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
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,
NATO UNCLASSIFIED 32
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
- Change PCM switch configuration,
- Change network configuration.
The acknowledgement for the completed change of IA configuration is sent back to the Fault Management.
Configuration Changed
Change Configuration Generic Triggered
or untriggeredReconfiguration
Configuration Changed
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.
NATO UNCLASSIFIED 33
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
Request LC Change
Generic TriggeredReconfiguration
Configuration ChangedLC
Changed
IA GSMAM
Figure B.11 – AM-Driven Change of IA Configuration
NATO UNCLASSIFIED 34
NATO UNCLASSIFIED STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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 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:
7. Reduced life cycle costs
8. Improved mission performance
9. 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 12 - ASAAC Standard Documentation Hierarchy
1.2 Document structure
The document contains the following sections:
NATO UNCLASSIFIED
1
NATO UNCLASSIFIED
STANAG 4626 (Part VI) (Draft 1)
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
Normative ReferencesNormative References
Section 2
Terms & DefinitionsTerms & Definitions
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
STANAG 4626 (Part VI) (Draft 1)
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 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
STANAG 4626 (Part VI) (Draft 1)
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
8. Final Draft of Proposed Standards for Software Document ref.: ASAAC2-STA-32410-001-SWG
9. Final Draft of Proposed Standards for Network Document ref.: ASAAC2-STA-32420-001-HWG
10. Final Draft of proposed standards for Common Functional Module Document ref.: ASAAC2-STA-32430-001-HWG
11. Final Draft of Proposed Standards for Packaging Document ref.: ASAAC2-STA-32440-001-HWG
12. 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
NATO UNCLASSIFIED
STANAG 4626 (Part VI) (Draft 1)
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
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
• 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,
Making all three time references available to its own OSL via the use of MOS services.
NATO UNCLASSIFIED
10
NATO UNCLASSIFIED
STANAG 4626 (Part VI) (Draft 1)
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).
Making all three time references available to its own OSL via the use of MOS services.
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
Request value of time reference
Trigger at start time theTime reference request
Reply with time reference value
Request value of time reference
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
(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
STANAG 4626 (Part VI) (Draft 1)
Figure A.1 - Time management principle sequence for the AGT distribution process
NATO UNCLASSIFIED
19
NATO UNCLASSIFIED
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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:
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 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
STANAG 4626 (Part VI) (Draft 1)
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,
To compute the current AGT,
To transmit errors to the Health Monitor.
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:
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 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
STANAG 4626 (Part VI) (Draft 1)
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),
To compute the current AGT,
To transmit errors to the Health Monitor.
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
(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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
∆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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
Where: tDi is the computation time of Di’
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
Where: tDi is the computation time of Di’
α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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
(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
STANAG 4626 (Part VI) (Draft 1)
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
STANAG 4626 (Part VI) (Draft 1)
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.