titel: dadi–ma introduction manual€¦ · (dadi–ma) users and operations manual. it provides...

Dokument Typ:

Titel:

Lieferbedingungs-Nr.:

Produktgruppe:

Schlagwörter:

Klassifikations Nr.:

Konfigurationsteil-Nr.:

Produktklassifizierungs-Nr.:

Freigabe Ordnungs-Nr.:

Bearbeitet:

Geprüft:

Abteilung: Firma:

Document Type:

Title:

DRL/DRD No.:

Product Group:

Headings:

Classification No.:

Configuration Item No.:

Classifying Product Code:

Release Order No.:

Prepared by:

Agreed by:

Department: Company:Genehmigt:Approved by:

Abteilung: Firma:Department: Company:

Genehmigt:Approved by:



Manual

DADI–MA Introduction Manual

N/A

MDA – Team RIT12 DASA/RI BRE

PR 1216401

MDA–DADIMA Concepts

N/A

1216401

8–QABA

N/A

A. Werkman RIT12 DASA/RIBRE

R. Zimmermann RIT14 DASA/RI

COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997

Dok.Nr./Doc. No.:AusgabeÜberarbtg. Datum

/Issue:/Rev.: /Date:

Datum/Date:

Raumfahrt-Infrastruktur

Daimler-Benz A erospace

FORM 0019.1/3 Daimler–Benz Aerospace, Bremen – All Rights Reserved – Copyright per DIN 34

vRaumfahrt-Infrastruktur

COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997ii

Daimler-Benz A erospaceDok.Nr./Doc. No.:AusgabeÜberarbtg.Seite

Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:

FORM 0672.0V.7 Daimler–Benz Aerospace AG, D–28199 Bremen – All Rights Reserved – Copyright per DIN 34

DOCUMENT CHANGE RECORD

Issue / Rev. Issue date Sections RemarksAffected

(1/ A) (28.07.95) (all) (initial version)

(1/ B) (20.09.95) 5.2.4.1 Update section for new Mapping function5.2.5 New parameter Aggregate Flag

(2/–) (01.12.95) 9 New section for Composite Aggregates

(3/–) (04.04.97) 2.1.2 Updated ICD reference


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997iii


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


TABLE OF CONTENTS

1 INTRODUCTION 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Identification and Scope 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Purpose 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 APPLICABLE AND REFERENCE DOCUMENTS 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Applicable Documents 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Reference Documents 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 OVERVIEW OF DADIMA–SPECIFIC CONCEPTS 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 DADI–MA scope within the MDA/MDB tool–set 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Concepts outside the DADI–MA scope 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1.1 Name–Tree & Configuration handling 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.2 Procedural access to MDB (P_MDB) 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.3 SID–Range definition 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2 Concepts inside the DADI–MA scope 3–5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 DATA DICTIONARY STRUCTURE 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Data Dictionary Components 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Versions 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Domains 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 End–Item–Types, Aggregates and Attributes 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 SHORT IDENTIFIER (SID) RANGE DEFINITION CONCEPTS 5–1. . . . . . . . . . . . . . . . . .

5.1 General SID & MDB Instance 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Distributed development supported by MDB Instance identification and SID rangeallocation 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 SID Range Administration 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 FLEXIBLE TOOL INVOCATION CONCEPTS 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 FOREIGN KEY CONCEPT 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 END ITEM MAPPING 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 COMPOSITE AGGREGATES 9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1 Variant Part References 9–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2 Foreign Key References 9–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3 Composite Aggregate Relations 9–5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A ACRONYMS A-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B DEFINITIONS B-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997iv


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


Figure 1. Data Dictionary Application within the MDA Architecture 3–1. . . . . . . . . . . . . . . . . . . .

Figure 2. Data Dictionary – Maintenance Application OVERVIEW 3–2. . . . . . . . . . . . . . . . . . . . .

Figure 3. Component Hierarchy within DADI–MA 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4. General End–Item structure 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5. End–Item example 4–5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6. SID–Range allocation to MDB Instances 5–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 7. Start Application Tool from different Scopes 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 8. Version Identification with Internal Keys 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 9. Version Identification with Complete String Keys 6–3. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 10. Flexible Tool Invocation Environment 6–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 11. General End–Item structure with Foreign Key 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 12. Example of a Foreign Key Definition 7–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 13. Foreign Key Environment 7–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 14. Set of provided standard aggregates & predefined End–Item–Types 8–2. . . . . . . . . . . . .

Figure 15. User defined End–Item–Types 8–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 16. The Name Tree including Standard End–Items & User–defined End–Items 8–4. . . . . . . .

Figure 17. End Item ’Shadowing’ 8–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 18. Option 3 : User defined arbitrary End–Item–Types 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 19. Transformation of user defined data structure content to CGS data structure 8–9. . . . . . .

Figure 20. Example: possible alternative operational scenario 8–10. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 21. Composite Aggregates consisting of ’Simple’ Aggregates 9–1. . . . . . . . . . . . . . . . . . . . .

Figure 22. The Diskriminant represented by one Attribute 9–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 23. The Foreign Key represented by one Attribute 9–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 24. A Composite Aggregate containing Variant Part and Foreign Key References 9–4. . . . . .


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997v


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


This page is intentionally left blank.

1–1Raumfahrt-Infrastruktur

COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19971–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


1 INTRODUCTION

1.1 Identification and Scope

This part is the Introduction Manual of the MDA–Data Dictionary Maintenance Application(DADI–MA) Users and Operations Manual. It provides an introduction of the DADI–MA concepts.

1.2 Purpose

This Manual provides an introduction to the Data Dictionary Maintenance Application DADI or DADI–MA.The Manual focuses on the Conceptual Model of the MDB definition by DADI–MA which is the basis forunderstanding especially for the Reference Manual part.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19972–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


2 APPLICABLE AND REFERENCE DOCUMENTS

Document No. Issue / Revision

Document Title

___________________________________________________________________________

2.1 Applicable Documents

2.1.1 SPE 1216 401 002 2/C 05.11.1993

MDA Requirements Specification

2.1.2 COL–RIBRE–ICD–0015–00 3/– 28.02.97

System to MDA Interfaces

2.2 Reference Documents

2.2.1 ADD 1081 717 002 2/– 15.05.1991

MPS Assembly Architectural Design Document


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


3 OVERVIEW OF DADIMA–SPECIFIC CONCEPTS

The Data Dictionary – Maintenance Application (DADI–MA) is a support tool to generate the data structuresand data structure support information to build up the Mission Database (MDB). DADI–MA and MDB are part of the overall Mission Database Application / Mission Database(MDA/MDB) architecture shown in figure 1.Different applications, like Interactive Data Entry, Data–API, etc. have interfaces to the MDB. The MDBis the central repository of information about flight configurations and its support systems. This kind ofinformation is stored and manipulated in the database as operational entities called End Items. Eachoperational entity must be defined and stored as an End Item in the MDB.

Unix

Oracle

Mission Database

Interactive Data Entry

Report

Generator

ImportExport

Consistency

Checker

Batch Data Entry

Data–API

Flexible Tool Invocation

Data DictionaryMaintenanceApplication

MDA ArchitectureMDB <–> Application Relation

Figure 1. Data Dictionary Application within the MDA Architecture

DADI–MA provides the capability to define the types of the MDB End Items and generates a Data Dictionarywhich will be exported to the MDB.

End Item Types are defined by their aggregates and attributes which is a structural decomposition.

Different versions of the Data Dictionary definitions can be managed. It includes the generation, archivingand re–usage, which supports the development evolution and maintenance.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


The figure 2. depicts the above said and shows the distinction of the MDB definition and generation as partof the DADI–MA and the MDB utilisation within the MDA/MDB environment.

.......APIBDEREPGEN EXIM CC ForeignTools

at runtime: MDA User

at DD definition time: MDB Administrator

Data Dictionary

software infrastructure layer (Oracle etc.)

data–structure & generics definition layer

Data Dictionary Maintenance Application (DADI–MA)

Consistency Rules;

Screen Forms Definition;

Foreign Tool Integration;

Report Definition;

End–Item–Type definition;

Application i/f definiton;

Batch Load definition;..

MDB

generateMDB

Figure 2. Data Dictionary – Maintenance Application OVERVIEW


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


For better understanding the Data Dictionary – Maintenance Application concept, a recall of the basicMission Database (MDB) concepts will be done.

· In the definition phase of the target system (typically a spacecraft), a step by stepdecomposition is performed. The defined hardware and software data will be organised in atree hierarchy, called the NAME–TREE.

· The name tree is divided into the SYSTEM–TREE and the USER–TREE (CDU), where theSystem Tree reflects the target system configuration design for a specific mission down toa specific level, e.g. subsystem or assembly level.The User Tree is the further decomposition of the System Tree items by subtrees. A CDU isa complete User Tree.

· The leaf nodes of the User Tree (CDUs) are called END–ITEMS. They contain the realdetailed data that have been defined for the specific devices.

· The CDUs are belonging to a DOMAIN (CDU Domain).

· Each End Item is of a given type, called END–ITEM–TYPE (e.g. Measurement,Telemetry–packet etc.).

The End–Item structure and breakdown is discussed in more detail in chapter 4 of this document.

In addition to this concepts some Mission Database Application implementation aspects need to bereminded. Mission Database Applications which have a direct relation to the Data Dictionary – MaintenanceApplication are:

· The Application Programmers Interface (API) that provides End–Item views andstore–procedures for data retrieval and storage. The API allows comfortable access to datastored in MDB without having to know the detailed MDB data organisation.

· The Batch Data Entry function (BDE) that allows for bulk data loading and relies on the BDEcontrol files for loading the type specific data (End–Item–Types) of an End Item into themission database.

· The Consistency Checker that supports to keep the data integrity.

· The Report Generator that provides System Tree, CDU, CCU and numerous other reports.

· The Interactive Data Entry Tool (IMDB) that provides a user interface for data entry intoMDB.

Above concepts and tools like the IMDB are relying on the definitions done as part of the Mission Databasedefinition performed with the DADI–MA.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


3.1 DADI–MA scope within the MDA/MDB tool–set

Not all MDA/MDB concepts are maintained and supported by DADI–MA. Therefore it is worth to knowwhat concepts are DADI–MA supported and which not.

3.1.1 Concepts outside the DADI–MA scope

3.1.1.1 Name–Tree & Configuration handling

The Name–Tree definition and structuring is an interactive function that can be performedjust with IMDB. DADI–MA is not involved in any Name–Tree handling neither in theSystem–Tree nor in the User–Tree definition. The RDBMS table structures for theName–Tree are created by the MDB installation scripts and maintained by IMDB and PMDB.

The Configuration Management aspects of the MDA/MDB like the System–Tree versionhandling and the CDU / CCU version handling are not supported by DADI–MA and are justhandled by IMDB.

3.1.1.2 Procedural access to MDB (P_MDB)

The procedural access to the MDB through PMDB is not supported by DADI–MA. ThePMDB is a set of ADA packages/procedures for MDB access, hiding the internal databasestructure to the user and providing by that a maximum of security.

3.1.1.3 SID–Range definition

The Short–Identifier range definition (SID–range) is not supported by DADI–MA. The SIDrange that has to be defined for each MDB instance is maintain by a separate tool calledSID–Range–Tool (SID–RT).

The SID–Range–Tool (SID–RT) and the SID–Range concept will be described in chapter 5 of thisdocument.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


3.1.2 Concepts inside the DADI–MA scope

With the help of DADI–MA the End–Item–Type design and definition is performed. This support is not onlylimited to the data structure definition itself but also to all aspect that are related to the data structures,namely:

· the definition of the Domains the End–Item–Types may belong to.

· the definition of End–Item–Types and related constraints e.g. the max. size of a VAR–SIZEdata type.

· the definition of constraints (consistency check rules) on a given data attribute e.g.MANDATORY, that means that an data element has to be filled in.

· the definition that a data element shall be printed as part of a report or displayed within IMDB.

· the Detailed–Data–Editor (DDED) is relying on the definitions made in DADI–MA. That ishow data aggregates and data attributes shall be presented in the IMDB to the user.

The detail data screen forms are generated at runtime by DDED. DDED is an integral part of IMDB.

· the Application–Programmers–Interface (API) is generated and configured based on the datastructure definition.

· the Batch–Data–Entry (BDE) control files are generated based on the data structuredefinition.

· the Flexible–Tool–Invocation interface is generated and configured based on the datastructure definition.

· the End–Item mapping mechanism, to map user defined end–item–types toStandard–End–Item–Types for Check–Out System and Simulation System usage.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19973–6


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


4



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


4 DATA DICTIONARY STRUCTURE

4.1 Data Dictionary Components

Hardware and Software configuration data of e.g. an onboard system or of a ground support system areperformed from a high abstract level to a detailed level until all data that are needed, to represent a valid datamodel, are defined. The data structures are defined and decomposed by a top down approach. Within thisdevelopment process different versions will be created and the data structure definition will be refined.

The decomposition within DADI–MA is defined by the components:

• Version

• Domain

• End–Item–Type

• Aggregate

• Attribute

Each of these components can be created, inserted, deleted and modified. The hierarchy and dependenciesbetween the components is shown figure 3.

Version 1.0 Domain 1

Domain 2

Domain 3

Domain N

End–Item–Type 1

End–Item–Type 2

End–Item–Type 3

End–Item–Type 4

End–Item–Type K

Aggregate 1

Aggregate 2

Aggregate 3

Aggregate 4

Aggregate 5

Aggregate L

Attribute 1

Attribute 2

Attribute 3

Attribute M

Version Y.Z

Figure 3. Component Hierarchy within DADI–MA


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


The above shown hierarchy shall show, that the following component dependencies have been defined:

• The data structure versions Version 1.0 up to Version X.Z have been defined

• Version 1.0 consist of the Domain 1 up to Domain N

• Domain 1 contains the end–item–types End–Item–Type 1 up to End–Item–Type K

• End–Item–Type 1 consists of the aggregates Aggregate 1 up to Aggregate L

• Aggregate 1 is composed of the attributes Attribute 1 up to Attribute M

4.2 Versions

The development of data structures usually needs several modifications in the development life cycle. Thesemodifications are caused by design changes and interface modifications. For this, different versions can behandled without loosing informations from the past.

To enable the designer to modify the data structure e.g. system design without loosing information of aprevious design status it is possible to work with different versions in parallel.

After a version has been created and reviewed, it can be exported to the MDB. Versions may different status:

• Not Exported

• Exported

Not Exported means, that the version is still under development and has not been exported to MDB.

Exported indicates, that the version has reached an appropriate status, so that the data structure may be filledwith data values within MDB.

Operations on a Data Dictionary versions are :

• creation of a new version

• modification of an existing version

• deletion of a version

• copying of a version


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


4.3 Domains

Domains are groups of End–Item–Types. A Domain refers to a set of related End–Item–Types where therelation may be logical, functional or operational depending on a specific environment or a specific purpose.Domains usually reflect the subsystems of the systems whose data structure shall be created.

Domains for an Orbital Infrastructure may be for example :

• On–Board Subsystem –> Data Management System (DMS)

• On–Ground Subsystem –> Electrical Ground Support Equipment (EGSE)

• Simulation Subsystem –> Software Simulation System (SSS)

Each of these subsystems contain End–Item–Types specific to their domain.

End–Item–Types are sharable, once defined it may be used within different domains.

4.4 End–Item–Types, Aggregates and Attributes

The general End–Item data structure breakdown is as depicted in the figure below.

– attribute 1– attribute 2

– attribute n


– attribute n


– attribute n

....

....

....

aggregate A1

aggregate A2

aggregate An

generic / intrinsic properties(name, ID, type, etc.)

other properties

End–Itemnode

Figure 4. General End–Item structure


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


The general layout of an end item does include the node and the node properties in the name tree as well asthe end item aggregates and attribute as the layered building blocks of the end–item itself.

Each end–item is of a given type, called End–Item–Type, e.g. an ’analog measurement’ with the name e.g.’pressure_in’ located in the ’onboard system’ within the ’thermal control subsystem’ (tcs) of the facility’waterpump’ (see example figure 5.). Each end–item does belong to a given domain, in our example the ’onboard system’ may represent a domainwith the name ’o/b_system’.

An end–item–type is comprised of one or more Aggregates which is a further decomposition, e.g. an’calibration coefficients’ aggregate is a decomposition of the ’analog measurement‘ type.

The aggregates themselves contain Attributes as a further decomposition, e.g. the x–value and y–valueattributes are a decomposition of the ’calibration coefficients’ aggregate.All attributes belonging to an end–item are grouped according to the aggregate structure.

Additionally an end–item may have special constraints, for example the aggregate describing the calibrationinformation of this pressure measurement shall have 5 point pairs and the aggregate itself shall be mandatory.

Mandatory means, that the end–item attribute values have to be present for any end–item of this type, e.g.the five x–values and five y–values of the calibration coefficients have to be filled for each end–item of thistype ’analog measurement’.Other attributes may be defined as optional, which means that the attribute values may be present or not.

In addition to the mandatory constraint definition, a uniqueness constraint and a range constraint forend–items can be defined.A uniqueness constraint defines that an attribute has to be unique within a configuration unit scope or anend–item scope. To specify that an end–item attribute shall be limited to a maximum and minimum value,a range constraint can be defined.

Those constraints are defined as part of the end–item aggregate and attribute definition.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


aggregate

end item

virtual node

agg abc

agg xyz

agg.: calibration

’calibration aggregate’5 pointpairs

attributes: x–value ; y–value

0 2.51.5 6.83.2 7.94.7 8.35.2 9.7

Constraint:mandatory aggr.;5 point pairs

onboard system

tcs

waterpump

name:’pressure_in’;owner: smithcreated: 1.1.95

E-I-Type:analog measurement

Domain:o/b_system

End–Item example

attributesx–valuey–value

Figure 5. End–Item example

For more detailed information about the end–item, aggregate and attribute definition with respect to datatypes of end–items (mainly applicable to cgs standard end–item–types), data types of attributes, aggregateand attribute consistency check definition please look into the DADI–MA Reference Manual (part no. 013).


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19974–6


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


5



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19975–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


5 SHORT IDENTIFIER (SID) RANGE DEFINITION CONCEPTS

5.1 General SID & MDB Instance

Generally the following operational scenario shall be taken to describe the SID and MDB–Instance conceptthat is supported by the MDA/MDB:

• MDB Data may be replicated / distributed over geographical dispersed locations.

• The Mission Database Software (MDA) ensures global consistency across all MDBInstances.

• Frozen Configuration Units may be freely exchanged among MDB Instances.

• Overall structure of the MDB (Common Data Dictionary) and distribution among Interna-tional Partners are determined by Prime Contractor.

• Of all identified MDB Instances one must be designated as the main (master) MDB; typical-ly this would be the prime contractor’s MDB.

Above said requires that for each MDB Instance the following must be defined:

– MDB Instance Identification: Each MDB Instance must be uniquely identifiable.

– SID allocation.: Each MDB Instance is assigned a dedicated SID Range ––> SID–Range Tool.

5.2 Distributed development supported by MDB Instance identification and SIDrange allocation

Flight configuration are usually developed at different locations. Due to the distributed development of flightconfiguration by several contractors at different locations, it must be possible to install the MDB at thesedifferent sites.

This also means that the MDB has to cover data distribution and integration mechanisms which allowcontrolled definition and modification of data at the same time but at different locations.

For example, an ISSA element contractor has decomposed his flight element in the MDB for a specificmission down to the subsystem level. Now it must be possible to further develop one subsystem at locationA and, at the same time, another subsystem at location B using the MDB.

At each different site the development teams wish only to see that data which they need to see for thedevelopment of their specific subsystem.

After the subcontractors at locations A and B have completed their subsystem design by definition of enditems, it must be possible to integrate both MDB data parts at an element contractor site.

So the MDB must provide a function for distributing data between different companies while still assuringdata consistency and integrity.

This implies that the MDB has to be installed for different purposes possibly at different locations, i.e. onan element contractor site an MDB will be installed and on each subcontractor site an MDB will be installedfor each development task: e.g. one installation for the team developing subsystem X and one for the teamdeveloping subsystem Y.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19975–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


But then, it would be possible that the team developing subsystem X defines the same name for the top levelsubsystem item as the team developing subsystem Y. The pathname of both top level subsystem items wouldthen be equal, which is not allowed within the Name Tree Concept.

In order to prevent users from defining the same item pathnames on different MDB installations, each ofthese installations is given an MDB instance name which is unique across all MDB installations. An ElementContractor will define, on which MDB Instance a subcontractor task might be performed since they areresponsible for designing element configurations on a high level and for passing on further design and finaldefinition tasks to subcontractors.

In order to prevent the MDB from generating the same or overlapping SID ranges on different MDBinstallations, each of these installations is given an SID range which is unique across all MDB installations.

If a subcontractor has defined all his end items he must deliver these to the element contractor who will thenintegrate the delivered data into the MDB of his instance.

To be able to support these data distribution and integration mechanisms the Name Tree Model has beenextended as follows:

In order to distinguish between the different development sites and their authorities, the Name Tree has beensplit in three parts:

1. the Element Configuration part which represents an overall element configuration design,

2. the System Tree part, modeling the element design down to e.g. subsystem or assembly level.The System Tree depends on the element configuration for a specific mission and is defined byone or more element contractors on their MDB element contractor instances.

3. The User Trees part, modeling further design steps down to end item level. The User Treesdepend on the System Tree and are defined by possibly different subcontractors on their MDBsubcontractor instances.

In order to assure data consistency and integrity during data distribution and integration, the System Treeand each User Tree is assigned a status which specifies whether it is still in a development phase or hasalready been completed. Before data can be distributed, it must be complete and its status must denote thatit can never be modified again.

5.3 SID Range Administration

It is the task of the SID–Administrator to coordinate and assign SID–Ranges to the different MDB Instancesto ensure that data can be exchanged and even more important integrated at the Master Instance. Theassignment of SID ranges is supported by a tool called SID–Range–Tool which is an Oracle application.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19975–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


ÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀ

RKA

MDB

MDB

ooo

ÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀ

ESA

MDB

MDB

ooo

MDB Instance RKA_1SID–Range e.g. 100000 – 1000000

MDB Instance RKA_NSID–Range e.g. 2000000 – 3000000

Instance ESA_NSID–Range e.g. 12000000 – 13000000

Instance ESA_1SID–Range e.g. 10000000– 11000000

ÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀ

NASA

MDB

Instance NASA_1SID–Range e.g. 4000000 – 5000000

MDB

Instance NASA_NSID–Range e.g. 8000000 – 9000000

ooo

Master:

MBF

Instance MASTERSID–Range e.g. 6000000 – 7000000

RKA Russian Space Agency ESA European Space Agency

NASA National Aeronautics and Space Administration

Figure 6. SID–Range allocation to MDB Instances


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19975–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


6



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19976–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


6 FLEXIBLE TOOL INVOCATION CONCEPTS

The flexible tool invocation function allows the integration of tools to be started from I_MDB. These toolscan be integrated from the customer himself in order to fulfil special demands. User application tools maybe attached to CDU versions, CCU versions and End Items so that they can be started from that specificscope.

The scopes in which a tool shall be available in I_MDB can be defined. A tool can be available for CCUversions and / or CDU versions ( configuration units ), so that whenever a configuration unit is selected inthe configuration unit window, the tool appears in the command menu and is executable from there.

A tool can also be available for a specific End Item Type within a CCU and / or CDU navigation scope ofthe I_MDB navigator window.

A tool can be started from four different scopes:

· For a CDU version within the CDU version window of I_MDB

· For a CCU version within the CCU version window of I_MDB

· For an End Item of a specific type and CDU navigation scope in I_MDB

· For an End Item of a specific type and CCU navigation scope in I_MDB

CDU CCU

ÉÉÉÉÉÉÉÉÉ

EIT

EIT

CDU

CDU

CCU

ÉÉÉÉ

EIT

EIT

CDU scope

CCU scope

End Item Type in CCU scope

End Item Type in CDU scope

CDUCDU

Figure 7. Start Application Tool from different Scopes


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19976–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


For an application tool one or more of the above mentioned scopes can be defined. Through the scopedefinition the availability of the application tool will be defined so that it is executable from that scope.

In the case of an End Item it is important which navigation scope has been selected in I_MDB. The navigationscope can be a CCU version and / or a CDU version, depending on the kind of configuration unit which hasbeen selected in order to navigate down to the End Item. Depending on the definition, it may be availablein a CDU version navigation scope, but not in a CCU version navigation scope.

One or more scopes can be defined for a tool. The scopes define the availability of a tool.

The interface to the tools consist of two parts:

· standard version identification parameters

· customer defined parameters

The version identification are standard parameters which are always provided. These standard parametersare provided in two different kinds depending on the scope for which a tool is called. Depending on the tool definition, the internal version keys are used or complete string keys. The twodefinitions are shown in Figure 8. and Figure 9.

‘CDU‘ ‘CCU‘ Flag to identify a CDU or CCU

cdu_internal_version ccu_internal_version Internal Version No.

sidend_item_type

Figure 8. Version Identification with Internal Keys


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19976–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


element_configuration

mission

system_tree_version

‘CDU‘ ‘CCU‘cdu_pathname

cdu_version

cdu_issue

cdu_revision

cdu_test_version

cdu_instance

ccu_pathname

ccu_name

ccu_version

ccu_issue

ccu_revision

Flag to identify a CCU or CDU

pathname

end_item_type

Figure 9. Version Identification with Complete String Keys

In addition to the version identification, customer defined parameters may be defined for each of the scopes.A parameter is defined by the following attributes:

· ordering of the parameter within the parameter sequence transferred to the tool

· parameter data type

· default parameter value for data entry in I_MDB

· tool invocation window field title for parameter definition in I_MDB

This parameter definition is optional. The parameter values are added at the end of the standard parameterswith the predefined ordering.

The customer defined parameters appear in the Tool Invocation window of I_MDB when a tool has beenselected. There the user can enter the parameter values and start the tool execution.Both, the standard version identification parameters and the customer defined parameters are provided asstrings.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19976–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


The dependencies between the Flexible Tool Invocation implementation and the MDA componentsDADIMA, MDB and the Tool are shown in Figure 10. The tool invocation definition performed in DADIMAcontains the tool description, the tool scope, and if needed the parameter description. All these informationsare exported to MDB.

I_MDB accesses the MDB to get the stored information about the tool invocation definitions. This includesthe menu entries for the tools in the specific navigation scope.

If no customer defined parameters exist, the tool will be started immediately with the standard versionidentification parameters.If customer defined parameters exist, a window is generated where the user can enter the actual values forthose parameters. When the user starts the execution, the tool is called with the standard versionidentification parameters and the added values of the customer defined parameters.

DADIMA I_MDB

Tool Description

Tool Scope

Parameter Description

MDB� �

Start Tool

Tool

�

Parameter Entry

Figure 10. Flexible Tool Invocation Environment


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19976–5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


7



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19977–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


7 FOREIGN KEY CONCEPT

A Foreign Key is used for the identification of items on foreign databases. It can serve as a cross referencebetween the MDB and other databases. Furthermore a Foreign Key can be used as an alternate access keywithin I_MDB.

The Foreign Key extends the capability to access MDB items which is normally done via the SID numberand pathname. This provides the possibility for other databases which use different data identifier than theSID and pathname from the MDB to access end items.

Each Foreign Key must be defined as an aggregate of end items. This definition will be done in the aggregateeditor of DADIMA by the MDA special usage field. Not necessarily all end items have to have this aggregateassigned. Attributes to this Foreign Key aggregates will be defined like any other attribute definition.

The general End–Item data structure breakdown including Foreign Keys is as depicted in the figure below.


– attribute n


– attribute n


– attribute n

....

....

....

aggregate A1

aggregate An

generic / intrinsic properties(name, ID, type, etc.)

other properties

End–Itemnode

Foreign Key FK1

Figure 11. General End–Item structure with Foreign Key


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19977–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


An example for a Foreign Key definition is shown in figure 12. This Foreign Key is named the ProgramUnique Signal Data Identifier (Signal PUI). To this Foreign Key the attributes Element, Functional System,Assembly, etc. have been defined.

Figure 12. Example of a Foreign Key Definition

The Foreign Key information, defined within DADIMA are exported to MDB. I_MDB accesses the MDBto get the stored information about the Foreign Key definitions. The data entry of the attribute values for theForeign Keys can be performed in I_MDB.A direct end item access in I_MDB is also possible by the defined Foreign Keys.

Syntax checks are performed by I_MDB according to the field definitions of the Foreign Keys by:

· validation of integer ranges

· validation of enumeration type values

The semantic correctness of the Foreign Key values can be defined through customer requirements. TheConsistency Checker of I_MDB performs the verification of the definition.

It is essential that Key Values are unique in a CCU or CDU version. This will also be checked by theConsistency Checker. Non uniqueness may occur:

· through the definition of a CCU version

· through the copy subtree operation, because the keys cannot be changed automatically as forSIDs

The MDA Batch Data Entry (BDE) tool provides operations for loading the type specific data of an end itemfrom an external database into the MDB. The Foreign Key identifier can be used to associate the input datafrom the external database to the respective MDB end items.The environment of the Foreign Key usage is shown in figure 13. The BDE concept is explained within theMDA reference manual more in detail.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19977–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


DADIMA I_MDB

Foreign Key Definition

Attribute Definition

MDB Attribute Value Entry

ExternalDatabase

BDE

Foreign KeysAggregates

Figure 13. Foreign Key Environment


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19977–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


8



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


8 END ITEM MAPPING

The Mission Database Application is not only used for Mission Support and Mission Data handling but alsoused as the Central Repository for Assembly Integration and Test activities (AIT) supported by the ESA –Columbus Ground System Facilities:

· System & Subsystem Checkout and Test Facility

· System & Subsystem Simulation Facility

· Design & Development Facility

The usage of the MDA/MDB in the ground avionics environment requires that specific End–Item–Typesneeds to be supported that are special to the Test & Checkout and Simulation Facility. Above mentionedEnd–Item–Types are called the CGS Standard End–Item–Types or CGS Standard Aggregates (whichmake–up the End–item types).

When using above mentioned ground facilities for e.g. Onboard Equipment check–out or O/B Softwarequalification the application that performs for example o/b data monitoring needs to know the structure anddata definition of the data to be monitored. On the other hand the ground facilities are using their own datastructure definitions the already mentioned Standard End–Item–Types or Standard Aggregates. This raisesthe problem that the monitoring function needs to know, how the onboard data can be acquired andinterpreted still using the applications known (standard) data definitions.

Two solutions are possible and supported by the DADI–MA.

· The usage of the standard end–item–type definitions and aggregates for end–item–typeconstruction.

· The mapping of end–item–types definitions to ground facility standard end–item–typesdefinitions.

Both solution are described in detail in the following chapters of this concept book.

The following figures shall illustrate the mapping concept.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


cgs_A1

cgs_A2

cgs_An

�

�

�

cgs_A3

– attribute 1– attribute 2– attribute 3

– attribute n

Standard aggregate

� � �

CGS_T1 CGS_T2 CGS_Tn

e.g. EGSE_FLOAT_MEASUREMENT

cgs_A3

cgs_A2

cgs_A5

cgs_A1

cgs_A4

cgs_A2

cgs_A1

cgs_A2

cgs_A3

Predefined end item types

Pre–defined end item types aremade up of Standard Aggregates

Figure 14. Set of provided standard aggregates & predefined End–Item–Types


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


USER_T1 USER_T1

cgs_A3

cgs_A2

usr_A3

usr_A4

usr_A5

usr_A3

usr_A4

usr_A5

usr_A1

usr_A2

User–defined end–item–types

CGS standardaggregates

User definedaggregates

User definedaggregates

case a: user E–I (pure) case b: user E–I (re–use)

pure user aggr. definition;no pre–defined standardaggr. has been re–used

two pre–defined standardaggregates have been used foruser end–item construction

Figure 15. User defined End–Item–Types


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


ÉÉÉÉÉÉ

ÉÉÉ

ÉÉÉ

ÉÉÉÉ

user

agg

rega

te

user

end

item

virt

ual n

ode

�

�

�

�

�

�

not a

ctua

lly p

art

of th

e na

me

tree

(sho

wn

here

for

com

plet

enes

son

ly)st

anda

rd a

ggre

gate

stan

dard

end

item

Figure 16. The Name Tree including Standard End–Items & User–defined End–Items


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


Several alternatives exist, all of them aiming at one common objective:Make arbitrarily defined data structures look like standard CGS data structures. In other words the originaluser data shall be transformed and presented in a manner that will enable CGS tools to perform as intended.

Option 1

· User–defined types have arbitrary structures

· ”CGS shadow” items are created at data entry time

This option requires the user to create a ”CGS shadow” end item for each user–defined enditem that is of interest to CGS. This shadow or duplicate shall have the appropriate CGSpredefined type (the one equivalent to the respective user–defined type) and will be enteredin the usual way using I_MDB or BDE.

MDB users / applications will selectively access the original or its CGS shadow as deemedappropriate.

Since MDA imposes no restrictions regarding the respective positions of end items in thename tree, end items could be ”shadowed” individually as well as by subtrees or CDUs asillustrated below (case A and B).

· The API is used by the user application to read/write the corresponding end items. Theflexible tool invocation function is used to invoke the user application to perform thedata mapping.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–6


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


ÉÉÉ ÉÉ

original

ÉÉÉÉÉÉ

� � �AB C

A1 B1C1

shadow

end item

end item

case A

ÉÉÉÉ

A

ÉÉÉÉÉÉ

B

ÉÉÉÉÉÉ

C A B C

original subtree or CDU shadow subtree or CDU

case B

original

shadow

end item

end item

Figure 17. End Item ’Shadowing’


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–7


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


Option 2

· User–defined end–item–types are CGS compliant

(i.e. the pertinent CGS standard aggregates have been used in the definition of these types)

In this case no special action is required from the part of the user since compatibility isautomatically ensured.

Option 3

· User–defined types have arbitrary structures

· CGS–compliant data structures are derived / generated by user–written software (CGSmapper)

This option requires an additional operational step in which all CGS required data structuresare generated.

As in option 1, two representations will exist in the MDB (original and CGS representation).In contrast however to option 1, both representations will be accessible through one and thesame pathname.

Option 3 is illustrated on the next page. Two cases are shown:

· Case A: Type usr_T1 consists of 2 CGS standard aggregates (cgs_A3 andcgs_A2) and 3 user–defined aggregates (usr_A3, 4, 5). So 2 of theexpected 3 aggregates are already accounted for. Only cgs_A5 will have tobe generated by user–written software.

· Case B: Type usr_T2 is entirely user–defined. In this case, cgs_A3,cgs_A2, cgs_A5 have all to be generated by software.

Development effort for the ” mapping software” may vary widely depending on:

· the number of types to be transformed

· the amount of compatibility between user–defined and CGS predefinedtypes(some user–defined types may be entirely incompatible , i.e. all aggregatesare non–standard; others may be only partially incompatible, i.e. one ormore CGS standard aggregates may have been used in the type definition).

· the complexity of the respective transformation algorithms.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–8


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


cgs_A3

cgs_A2 cgs_A2

cgs_A5

cgs_A3

structure expected by CGSusr_T1

to be generated

usr_A3

usr_A4

usr_A5

case A

cgs_A2

cgs_A5

cgs_A3

usr_A3

usr_A4

usr_A5

usr_T2

usr_A1

usr_A2

structure expected by CGS

to be generated

case B

Figure 18. Option 3 : User defined arbitrary End–Item–Types


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–9


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


cgs_A3

cgs_A2 cgs_A2

cgs_A5

cgs_A3

usr_T1

F1(x)

transformationalgorithm

usr_A3

usr_A4

usr_A5

case ACGS view of usr_T1after generation of cgs_A5

cgs_A2

cgs_A5

cgs_A3

usr_T2CGS view of usr_T2

F1(x)

transformationalgorithms

F2(x)

F3(x)usr_A3

usr_A4

usr_A5

usr_A1

usr_A2

case B

after generation of cgs_A3,2 & 5

Figure 19. Transformation of user defined data structure content to CGS data structure


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–10


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


One operational alternative how to handle the ”mapping software” is to collect all transformation functionsinto one maybe ”CGS–Mapper” called Support–SW–Product.

MDB

Master Database(central repository)

user–providedtransformation

S/W

generated data structure

CGS view

CGS mapper

Figure 20. Example: possible alternative operational scenario


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19978–11


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


9



COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


9 COMPOSITE AGGREGATES

The MDA data dictionary consists of a set of aggregates. Each aggregate is assigned to one or more types.So far the aggregates belonging to a type are independent from each other, except that they all contain recordsof the same end item.

A so called composite aggregate can be constructed by grouping aggregates. A composite aggregate is anaggregate on a higher level consisting of simple aggregates. All aggregates of a composite aggregate aredisplayed in the same window in the user defined sequence.

Composite aggregates are defined independently from end item types. A composite aggregate can beassigned to one or more end item types.

agg1 agg2

agg3

agg4

agg5

comp1comp2

simple aggregates

composite aggregates

Figure 21. Composite Aggregates consisting of ’Simple’ Aggregates

Constraints on Composite Aggregates:

� A composite aggregate cannot contain a composite aggregate.

� The set of aggregates of a composite aggregate contains no double entries.

For a composite aggregate relationships and dependencies between its aggregates can be defined. These arethe variant part and foreign key references which are described on the following pages. The term ’foreignkey’ is used in the sense of relational database concepts and not in the MDA specific meaning (a key to otherdatabases beside the MDB).


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


9.1 Variant Part References

For the aggregates of a composite aggregate a variant can be described. Such a variant is similar to theconstruct ’variant record’ in ADA. For this purpose a subset of the aggregates is defined as the variant part.One special attribute of an aggregate represents the discriminant. The field type of this attribute must be anenumeration type. According to each value of the enumeration type zero, one ore more aggregates can bedefined which will be visible in the window if the discriminant contains this value.

aggregates of comp1

agg1att1att2

agg2discriminant =>att1 : boolean

att2

aggregates of variant

agg3 agg4

TRUE FALSE

Figure 22. The Diskriminant represented by one Attribute

Constraints on Variants:

� A variant can only be defined for a composite aggregate.

� A variant can only contain aggregates which are part of the composite aggregate.

� Only one variant with one discriminant can be defined for the same compositeaggregate.

� The aggregate with the discriminant shall only be followed by aggregates of thevariant, i.e. the complete variant shall appear at the end of the sequence of aggregatesof the composite aggregate.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


9.2 Foreign Key References

For the aggregates of a composite aggregate foreign key references can be defined, i.e. an attribute of oneaggregate is the foreign key to one or more other aggregates.

aggregates of comp1

agg1att1att2

agg2

att2

agg3 agg4att1

att2

att1

att2

att1

att3 att3att4

foreign key =>

Figure 23. The Foreign Key represented by one Attribute

Constraints on Foreign Key References:

� A foreign key reference can only be defined between aggregates of a compositeaggregate.

� Only one aggregate can contain a foreign key attribute per composite aggregate.

� The name of the foreign key attribute has to be the same in all referenced aggregates.

� The foreign key attribute must not be a discriminant.

� The referenced aggregate must be a multi–record aggregate.

� A foreign key attribute from outside a variant must not reference an aggregate whichis part of a variant. For example the attribute att2 of the aggregate agg1 cannotreference aggregate agg3 which is part of a variant.

� An aggregate cannot reference itself.

� An aggregate cannot be referenced more than once.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


The following figure shows a composite aggregate with a variant part and foreign key references.

aggregates of comp1

agg1att1att2

agg2discriminant =>att1 : sw_type

att2

aggregates of variant

agg3 agg4

INTEGER FLOAT

att2

att1

att2

att1

att3 att3att4

foreign key =>

Figure 24. A Composite Aggregate containing Variant Part and Foreign KeyReferences


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


9.3 Composite Aggregate Relations

� A composite aggregate can be assigned to zero or more End–Item–Types.

� An aggregate can be assignded to zero or more composite aggregates. A compositeaggregate can contain zero or more aggregates.

� An aggregate can contain of zero or more attributes. An attribute belongs exactly toone aggregates, i.e. attributes of different aggregates can have the same name.

� A composite aggregate can contain zero or one discriminant. An attribute of anaggregate can be the discriminant of zero or more composite aggregates. Thediscriminant can only be an attribute of an aggregate which is part of the compositeaggregate.

� The discriminant of a composite aggregate can reference zero or more aggregatesto be part of its variants. An aggregate of a composite aggregate can belong to zeroor more variants of the discriminant. The variants of the discriminant are determinedby the values it can become.

� The variants of the discriminant within a composite aggregate can reference zero ormore values of the enumeration type to which the discriminant belongs. Anenumeration type value can be referenced by zero or more discriminant variants.

� A composite aggregate can contain zero or one aggregate with a foreign keyattribute. An attribute can be the foreign key attribute of zero or more compositeaggregates.

� A foreign key aggregate of a composite aggregate can reference zero or moreaggregates. An aggregate of a composite aggregate can be referenced by zero or oneforeign key aggregate.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.19979–6


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


10


NO TAGRaumfahrt-Infrastruktur

COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997A-1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


A ACRONYMS

AP Automated Procedure

API MDA – Application Programmers Interface

APM Attached Pressurized Module

BDE Batch Data Entry Tool

CCU Configuration Control Unit

CDU Configuration Data Unit

CLS Columbus Language System

CM Configuration Management

CU Configuration Unit

DADI Data Dictionary Tool

DADI–MA Data Dictionary Tool ( –MA Maintenance Application)

DD Data Dictionary

DMS Data Management Subsystem

EGSE Electrical Ground Support Equipment

EI End Item Type

ICD Interface Control Document

IMDB Interactive Mission Database

MDA Mission Database Application

MDB Mission DataBase

SID Short Identifier

SSMB Space Station Manned Base

TCS Thermal Control Subsystem

UCL User Control Language


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-1


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


B DEFINITIONS

A

Access rights define what access various users or applications have to objects or entities.

Action Actions are high–level commands which provide for a flight configurationcontrol at higher levels than elementary commands and AutomatedProcedures (AP). They are pre–planned, goal–oriented operations ofeither Payload Elements or Subsystems. An Action may be linked tolower–level actions reflecting the hierarchical decomposition of theon–board operation. On Action level, all necessary pre–checks are carriedout to ensure a safe implementation of an automated operation consistentwith the actual mission phase and flight element configuration.

Application Program or set of programs performing some specialized user–orientedfunction (as opposed to general–purpose programs like a DBMS, or anoperating system).

Archive Refers to the process of relegating obsolete data to external backingstorage. The reverse operation (copying archived data back to activestorage) is known as restore.

Authorized User see User

Automated Procedure A program written in the User Control Language (UCL).

B

C

CDU domain is a set of item types

Child in a hierarchical structure, denotes an immediate descendant of a givencomponent. A child is thus located one hierarchical level below its parent.

Compilation Unit Smallest unit of code that is accepted by the compiler. In UCL, there are3 types of Compilation Units: Automated Procedure (AP), LibrarySpecification, and Library Implementation (or Library body).

Component Component is a generic term used to cover any item in the higher levelsof the software architecture (i.e. product, assembly and subsystem).

Configuration Unit (CU) Collection of MDB items treated as a single unit for configurationmanagement purposes.CUs are of two kinds: (a) Configuration Data Units (CDU), which contain the actual data(b) Configuration Control Units (CCU), which contain referenceinformation (CU name, version number, etc.) about other CUs, just like adirectory in a file system.

Configuration Control Unit (CCU)A Configuration Control Unit is a Configuration Unit used to define andcontrol other Configuration Units. It identifies which specific


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-2


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


combinations of CDU instances make up a particular configuration. AConfiguration Control Unit may, in turn, point to lower–level controlunits, thus leading to a hierarchical configuration tree whose topmost(root) component corresponds to an entire Columbus FlightConfiguration.

Configuration Data Unit (CDU)Configuration Data Units are composite entities containing the actual dataitems (grouped into individual units for configuration managementpurposes).

Consistency Consistency is the software characteristic that ensures uniform design andimplementation techniques and notations.

Consistency state LOCAL VALID,LOCAL INVALIDGLOBAL VALIDNONE

D

Database A common or integrated collection of interrelated data whose purpose isto serve one or more applications.

Database Management System (DBMS)The software responsible for the actual definition, storage andmanipulation of data in a Database at both the physical and logical level.

Database Administrator (DBA)The person(s) responsible for the operation and maintenance of a DBMS.

Data Entry / Data MaintenanceGenerally refers to the process of entering and/or updating data in thedatabase. In this context, the term ”maintain” refers to any operation which altersthe state of the Database, i.e. add (insert) new data, modify existing data,or delete data.

Database integrity Refers to the state in which the database is considered to be undamaged(both physically and logically).

Database Server Refers to the processor (network node) physically hosting the Databaseand providing DB access services to local or remote applications (clients).

DBA see Database Administrator

DBMS see Database Management System

Default a value supplied by the system when a user does not specify a requiredparameter, qualifier, or attribute.

Distributed Database A collection of databases that can be operated and managed separately andalso share information.

Distributivity Distributivity is the degree to which software functions are geographicallyor logically separated within the system.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-3


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


E

End–Item see MDB item

Export In the MPS context, this term refers to the process of extracting data froma DB and preparing it for inclusion (import ) into another DB.

F

G

GLOBAL VALID All consistency rules are fulfilled. That implies that all internal referencesare existing and external references do not exist.

Ground Software All software that executes in any COLUMBUS ground computer or in theflight configuration computers during pre–launch ground operations.

H

Hierarchical Name Tree see Name Tree

I

Import In the MPS context, this term refers to the process of receiving or includingdata from an external (possibly remote) DB into the local DB.

Issue see Version

MDB–Item instance an occurrence of a particular MDB item in a given CU version.

J

K

L

LOCAL INVALID Internal references are not existing or other consistency rules as defined inthe MPSICD are not fulfilled.

LOCAL VALID All internal references and all other consistency rules are correct. Externalreferences are still existing and cannot be checked.

M

MDB instance One installation of an MDB with a specific SID range.

MDB installation node Server where one or more MDB’s are installed.

MDB Item, MDB Object In the context of this document, these two terms are used interchangeablyto denote a uniquely identifiable entity that has been defined in the MissionDatabase ( and corresponds to a real–world HW or SW entity). An MDB


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-4


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


Object or Item may be decomposed into lower–level items according to thehierarchical nametree conventions, see Nametree below. An End–Item is an MDB item located at the lowest hierarchical level (leafor terminal node), and hence cannot be further decomposed.

Mission The performance of a coherent set of investigation or operations in spaceto achieve space programme goals. A single mission may require morethan one flight, and more than one mission may be accomplished on asingle flight.

Mission Database (MDB) This is the central repository for all HW / SW configuration informationabout Columbus Flight Elements, Payloads and associated GroundSupport Equipment. Access to the MDB is controlled and managed byMPS.

N

Nametree Hierarchical (tree) structure within the MDB which portrays thehierarchical decomposition of Columbus Flight Configurations intosystems, subsystems, equipment, etc. The topmost node of the nametree(called the root node) designates the Flight Configuration, whereasterminal nodes (leaf nodes) represent the items that cannot (or need not)be further decomposed, i.e. the so–called end–items.Each MDB object is thus identifiable by a pathname indicating thesuccession of nodes to be traversed to reach that particular item in theNametree.

Node any component of a network or tree structure.(e.g. LAN node, nametree node)

O

Operating System (OS) The system software that controls the computer and its parts, performingthe basic tasks such as allocating memory, and allowing computercomponents to communicate.

P

Parent In a hierarchical structure, denotes an immediate ancestor of a givencomponent.

Pathname see Nametree

Q

R

Reconfiguration A procedure which changes the status of used hardware and software items

Report In the context of this document, a report may be defined as anyhuman–readable description of one or more MDB items. It is an assorted


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-5


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


collection of information usually presented to the user in form of a tableor itemized list (tabular format).A report’s specification contains the instructions for generating the report,e.g. data selection criteria, formatting instructions, and sort order. Thisspecification may be stored in the MDB. On request, a report is generated, i.e. the predefined instructions areexecuted, and the resulting output routed either to the workstation’s screen(on–screen report), to the printer or to a user–selected file.

Revision see Version

S

System Administrator A person responsible for the operation and maintenance of the operatingsystem of a computer.

T

U

Unit Unit is a generic term used to cover any lower level item of breakdown inthe software architecture e.g. module, object etc.

User Throughout this document the term User refers to any person usingMDA–provided services. Users are grouped into different classes orcategories and will be assigned different privileges based on the task theyperform.

V

Version In the course of its life cycle, a Configuration Unit (CU) usually undergoesseveral modifications due to evolving user requirements, design changes,etc.It will thus possibly exist within the MDB in many different forms orinstances (CU occurrences) commonly referred to as versions, e.g. DMSVersion 3.2.1.

In the Configuration Management (CM) context, however, the various CUoccurrences are classified according to the types of changes that have beenmade. The terms versions, issues, and revisions are then used todifferentiate between the following 3 cases:– Modifications due to requirements changes which result in a newversion– Modifications due to design changes which result in a new issue.– Modifications due to bug fixes, repairs or other corrections (affectingneither the design nor the requirements) which result in a new revision.


COL–RIBRE–MA–0037–003 01.12.1995– 04.04.1997B-6


Datumvon

/Issue:/Rev.:

/Page:/Date:

/of:

Datum/Date:


(In the above example, the CU Identifier ”DMS Version 3.2.1”, therefore,refers to Version 3, Issue 2, Revision 1 of the DMS)

W

X

Y

Z