scos-2000 obsm external interfaces control...

ESA/TOS-GCI

Document Reference: S2K-MCS-ICD-0014-TOS-GCIDocument Status: 1.3Prepared By: SCOS-2000 TeamDate: July 11, 2001

SCOS-2000OBSM External Interfaces

Control Document

Ref.: S2K-MCS-ICD-0014-TOS-GCIIssue: 1.3Date: 11/07/2001

SCOS-2000 OBSM External Interfaces ICD Page: 1

0 SERVICES

0.1 Approval sheet

Prepared bySCOS-2000 Team

Checked by Organisation Signature DateG. P. Izzo VITROCISET

Approved by Organisation Signature DateS. Haag ESOC, TOS-GCI

Authorised by Organisation Signature DateM. Pecchioli ESOC, TOS-OFM

M. Jones ESOC, TOS-GCI

© COPYRIGHT EUROPEAN SPACE AGENCY, 1995, 1996, 1997

The copyright of this document is vested in the European Space Agency. This document may onlybe reproduced in whole or in part, stored in a retrieval system, transmitted in any form, or by anymeans electronic, mechanical, photocopying, or otherwise, with the prior permission of theEuropean Space Agency.



0.2 Document Status Sheet

Document Title SCOS-2000 OBSM External Interfaces ICD

Issue Revision Date Reason for Change

1 0 Oct 27, 1999 First issue.

1 1 Dec 14, 1999 Handling of Addressing Unit in the Imagesimport/export files.

1 2 Aug 23, 2000 Addition of the header in the exported imagefiles. Implementation of the approved DCRslisted in Annex 1.

1 3 Jun 11, 2001 Implementation of the non-editorial changeslisted in Annex 1.



Abstract

This document is the interface control document of the file based external interfaces supported bythe SCOS-2000 OBSM applications. It covers the import of memory devices and memory modelsdefinitions as well as the import and export of memory images. Data in the suitable format aretypically generated by off-line system of any client mission using SCOS-2000. This document onlycovers the ‘generic’ portion of the static data which are relevant to functions supported by theSCOS-2000 OBSM subsystem. Mission specific extensions are possible.



Table of Contents

0 SERVICES ................................................................................................................................................................................... 1

0.1 Approval sheet ....................................................................................................................................................................... 1

0.2 Document Status Sheet ......................................................................................................................................................... 2

1 Introduction................................................................................................................................................................................. 6

1.1 Purpose ................................................................................................................................................................................... 6

1.2 Scope ....................................................................................................................................................................................... 6

1.3 Overview ................................................................................................................................................................................. 6

1.4 Definitions, Acronyms and Abbreviations........................................................................................................................ 6

1.5 References............................................................................................................................................................................... 61.5.1 Applicable Documents................................................................................................................................................61.5.2 Reference Documents .................................................................................................................................................7

2 Memory Devices Import Interface Specification ............................................................................................................... 8

2.1 General Description ............................................................................................................................................................. 8

2.2 Scope ....................................................................................................................................................................................... 8

2.3 Assumptions and Constraints.............................................................................................................................................. 8

2.4 Location and Naming Convention of the ASCII Files..................................................................................................... 8

2.5 Structure of the ASCII Files................................................................................................................................................. 9

2.6 Detailed Definition of the Table Records Structure........................................................................................................ 92.6.1 Memory Devices File: mdf.......................................................................................................................................102.6.2 On-Board Processors Definition File: pdf.............................................................................................................112.6.3 Device Connection File: dcf.....................................................................................................................................12

3 Memory Models Import Interface Specification..............................................................................................................13

3.1 General Description ...........................................................................................................................................................13

3.2 Scope .....................................................................................................................................................................................13

3.3 Assumptions and Constraints............................................................................................................................................13

3.4 File Naming Convention....................................................................................................................................................13

3.5 Detailed Description of the Memory Model Files .........................................................................................................143.5.1 Structure of the Memory Model file header..........................................................................................................153.5.2 Structure of the Memory Area Definition records ...............................................................................................15

4 Memory Images Import/Export Interface Specification...............................................................................................18

4.1 General Description ...........................................................................................................................................................184.1.1 Memory Images Import ............................................................................................................................................184.1.2 Memory Images Export ............................................................................................................................................19

4.2 Scope .....................................................................................................................................................................................19

4.3 Assumptions and Constraints............................................................................................................................................19



4.4 File Naming Conventions..................................................................................................................................................20

4.5 Detailed Description of the Memory Image Import Files.............................................................................................20

4.6 Detailed Description of the Memory Image Export Files ............................................................................................24

Annex 1: List of implemented changes........................................................................................................................................25



1 INTRODUCTION

1.1 Purpose

This document is the interface control document of the file based external interfaces supported bythe SCOS-2000 OBSM applications. Data in the suitable format are typically generated by off-linesystems of the client missions using SCOS-2000.

1.2 Scope

This document covers the following OBSM external interfaces:

Ø The import of memory devices and processors definition files.

Ø The import of memory model definition files.

Ø The import of memory image files.

Ø The export of memory image files.

Remark: note that memory processors, devices and models were all imported into the run-timedatabase in the SCOS-2 OBSM implementation and thus their import was covered by the SCOS-2MIB ICD.

1.3 Overview

This document is organised as follows:

Section 1: IntroductionSection 2: Memory Devices Import Interface SpecificationSection 3: Memory Models Import Interface SpecificationSection 4: Memory Images Import/Export Interface Specification

1.4 Definitions, Acronyms and Abbreviations

A complete list of definitions, acronyms and abbreviations used within the SCOS-2000 project isavailable in [RD-1].

1.5 References

1.5.1 Applicable Documents

Doc. Reference TitleAD-1 S2K-MCS-SRD-0005-TOS-GCI SCOS-2000 OBSM SRD



1.5.2 Reference Documents

Doc. Reference TitleRD-1 S2K-MCS-GLO-0001-TOS-GCI SCOS-2000 Glossary, Definitions and Acronyms

RD-2 S2K-MCS-ICD-0001-TOS-GCI SCOS-2000 Database Import ICD

RD-3 S2K-MCS-SUM-0021-TOS-GCI SCOS-2000 FARC Software User Manual

RD-4 ESA PSS-07-101 Packet Utilisation Standard

RD-5 S2K-MCS-SUM-0002-TOS-GCI SCOS-2000 Configuration and Installation Guide



2 MEMORY DEVICES IMPORT INTERFACE SPECIFICATION

This Section specifies the SCOS-2000 OBSM external interface supporting the import of static datadescribing the Memory Devices and Memory Processors.

2.1 General Description

The data source consists of a set of ASCII files describing the characteristics of Memory Devicesand Memory Processors. One ASCII file will contain all data belonging to one table (e.g. the mdffile will contain the characteristics of all Memory Devices).

The Memory Devices and Processors definition data are typically imported/activated as follows:

Ø The client mission data are converted/exported from the off-line database system (based on e.g.ORACLE, MS-Access, etc.) into ASCII files conforming to the structure specified in thisdocument.

Ø These ASCII files are transferred into a specific directory accessible from the workstationrunning the SCOS-2000 OBSM.

Ø The static data are then active as soon as the SCOS-2000 OBSM desktop is restarted.

2.2 Scope

This ICD only covers the definition of the ASCII files as expected by the SCOS-2000 OBSMDesktop. It does not cover the generation and transfer of these files into the appropriate location.

2.3 Assumptions and Constraints

The ASCII files will have to respect the exact structure described in the present document. EachASCII file provided by the mission consists of a set of records all based on the same structure.Mission specific extensions are possible by appending additional fields at the end of each record.

This ICD does not impose any specific constraint in the way that the ASCII files are generated andmaintained in the off-line database system (mission specific).

Remark: Note that no consistency check will be applied by the OBSM desktop at data loading time.It is the responsibility of the off-line system to ensure consistency of the data.

2.4 Location and Naming Convention of the ASCII Files

The transfer of the ASCII files will have to be performed by the mission onto a directory accessibleby its own SCOS-2000 OBSM system. The name and path of the directories where the ASCII fileshave to be located is configurable by client missions in the MISCConfig file.



Each ASCII file shall be given the name of the corresponding table (see Section 2.6 below) in lowercase with an extension .dat (e.g. mdf.dat).

2.5 Structure of the ASCII Files

In this section, the structure of the ASCII files imported by the SCOS-2000 OBSM Desktop isdescribed. The following applies:

Ø Each file will contain one line per record with the structure specified in the corresponding table(see Section 2.6 below).

Ø The field separator is a Tabulation.

Ø The end-of-file convention is EOF.

Ø Fields that are required by client missions and are not part of the tables described below, have tobe added at the end of the table.

2.6 Detailed Definition of the Table Records Structure

In the following sections, the structure of the records for each ASCII table supported by the SCOS-2000 OBSM Desktop is described in a tabular form. The tables have to be read as follows:

Ø Each field of a table is given a name, corresponding type and description, and an indication ofwhether the field is mandatory (i.e. it cannot be left Null).

Ø The field type is specified to be either ‘Number’ or ‘Char’. Only integer values (signed orunsigned) are allowed to be specified for field of type Number. Field of type Char allow anyalphanumeric ASCII characters i.e. A-Z and 0-9. Underscore, plus/minus, dot and dashcharacters are also allowed. Other ASCII characters shall be avoided. Also note that the formatof a specific field can be further constrained by its nature e.g. a SCOS-2000 TM Packet ID canonly be an unsigned integer number greater than zero.

Remark: It is recommended not to use ‘space’ characters within names i.e. within the alphanumericstrings used for unique identification of a database item (e.g. a parameter name). Further, theuniqueness of names shall be ensured without considering the case of alphabetical characters e.g.two memory devices with names DEV_01 and Dev_01 are not allowed.

Ø All the field lengths have to be considered as a maximum length for that field i.e. it is allowedto specify values with less digits/characters than the maximum field length.

Ø If a row/table is with grey background, it means that the field/table is imported but not used bythe SCOS-2000 OBSM Desktop for any processing. Typically, these fields/tables are left overfrom previous implementations.

Ø If a row/table is in italics, it means that the field/table is imported but not directly used by theSCOS-2000 OBSM application. Typically, these fields contain data which may be required bymission specific applications (e.g. the patch/dump command generator) or which areplaceholders for mission specific extensions (e.g. handling of on-board processors).



Ø An ‘M’ in the final column indicates a mandatory field i.e. a field which cannot be left Null.

Ø Fields which are not mandatory may or may not be explicitly given a value. Optional or unusedfields which are left Null shall anyway be considered in that the field separator charactercorresponding to that field shall be present.

The SCOS-2000 OBSM Desktop supports the following ASCII tables (one file per table):

Ø mdf: memory device file, defining the attributes of the on-board memory devices.

Ø pdf: processors definition file, containing the definition of on-board processors (not used by theSCOS-2000 OBSM Desktop).

Ø dcf: device connection file, defining the connections between the on-board processors and thememory devices (not used by the SCOS-2000 OBSM Desktop).

2.6.1 Memory Devices File: mdf

The mdf table defines the attributes of the on-board memory devices. One record per memorydevice.

Fi.Nr Field name Field Type Description Ma1 MDF_NAME Char(8) Name of the memory device.

An alphanumeric string uniquely identifying thememory device.

M

2 MDF_DESC Char(20) A textual description of the memory device used fordisplay purposes.

3 MDF_DPID Number(10) SCOS-2000 Packet ID of the associated dump packet.

An unsigned integer number matching with thePID_SPID (see [RD-2]) of the TM packet containingthe dump data to be processed in order to maintain thememory images related to this memory device.

4 MDF_SMAP Char(8) Spare field. Left-over from previous implementations.

5 MDF_CMAP Char(8) Spare field. Left-over from previous implementations.

6 MDF_PATCH Char(8) Name of the patch command that the memory device isassociated with.

An alphanumeric string matching with theCCF_CNAME (see [RD-2]) of the command to beused in order to patch this memory device.

7 MDF_DUMP Char(8) Name of the dump command that the memory device isassociated with.

An alphanumeric string matching with theCCF_CNAME (see [RD-2]) of the command to be



Fi.Nr Field name Field Type Description Maused in order to dump this memory device.

8 MDF_SPID Number(10) SCOS-2000 Packet ID of the memory packetassociated to this memory device.

Note: this field is only applicable in case the SCOS-2000 history files are used to archive memory images(i.e. in case the MISCconfig variableOBSM_IMAGE_ID_FILE is not set to “FARCmanager”). In this case, it is used by the OBSMdesktop to identify the history file to be used to storeand retrieve the reference images associated to thismemory device.

9 MDF_TYPE Number(2) Identifier of the memory device type. It can be used bythe client missions in order to identify the specificprocessing to be applied to images belonging to thismemory device (e.g. algorithm to be applied for thecalculation of checksum, applicable structure for thepatch and dump commands to be generated and forthe TM dump packets to be processed).

An unsigned integer number in the range (0..255).

Note: In the SCOS-2000 OBSM this field is not usedas the algorithm used to calculate the checksum forthe images associated to any memory device is theCyclic Redundancy Code (see the Packet UtilisationStandard, [RD-4] Appendix A.2).

‘0’

10 MDF_BASE Number(1) Integer number specifying the number of bytes whichconstitute the addressing unit of this memory device(see also Section 4.5 below):

‘1’ – for bytes

‘2’ - for words

‘4’ - for 32 bit words.

Note: this optional field is only used if specified inorder to determine the compatibility between memorydevices and associated memory images.

2.6.2 On-Board Processors Definition File: pdf

The pdf table defines the attributes of the on-board processors. One record per on-board processor.

Fi.Nr Field name Field Type Description M



1 PDF_NAME Char(8) Name of the processor.

An alphanumeric string uniquely identifying the on-board processor.

M

2 PDF_DESC Char(20) Textual description of the on-board processor.

2.6.3 Device Connection File: dcf

The dcf table defines the connections between the on-board processors and the memory devices.One record per connection. This allows cross-coupling between memory devices and on-boardprocessors.

Fi. Nr Field name FieldType

Description M

1 DCF_PROC Char(8) Name of the processor (PDF_NAME) that thisconnection definition is to be applied to.

M

2 DCF_DEVICE Char(8) Name of the memory device (MDF_NAME) that thisconnection definition is to be applied to.

M

3 DCF_ACCESS Char(1) Flag identifying the type of connection between thedevice and the processor.

‘C’ - for currently connected

‘A’ - for accessible.



3 MEMORY MODELS IMPORT INTERFACE SPECIFICATION

This Section specifies the SCOS-2000 OBSM external interface supporting the import of static datadescribing the Memory Models.


The data source consists of an ASCII file describing the characteristics of a Memory Model. EachASCII file will contain all data relevant to one single Memory Model.

The Memory Models definition files are typically imported/activated as follows:

Ø The client mission data are converted/exported from the off-line editor into ASCII filesconforming to the structure specified in this document.

Ø These ASCII files are transferred into a configurable directory (see [RD-5]).

Ø The Memory Model files are imported one by one into the OBSM Desktop by selecting theproper file.

Ø The user is now able to save the model in the SCOS-2000 File Archive and make it availablefor later retrieval by specifying its name, an Archive ID (identifying the catalogue in which thisfile will appear) and the Memory Device to which the model is associated. In case anothermodel with the same name is already present in the selected Archive, the next applicableversion number is automatically assigned and used (along with the Archive ID and modelname) to uniquely identify the Memory Model inside SCOS-2000.

3.2 Scope

This ICD only covers the definition of the Memory Model files as expected by the SCOS-2000OBSM Desktop. It does not cover the generation and transfer of these files into the appropriatelocation.


The Memory Model files will have to respect the exact structure described in the present document.

This ICD does not impose any specific constraint in the way that the Memory Model files aregenerated and maintained in the off-line system (mission specific).

Remark: no consistency check will be applied by the OBSM desktop at Memory Model loadingtime. It is the responsibility of the off-line system to ensure consistency of the data.

3.4 File Naming Convention



The file name will determine the Memory Model name as displayed in the OBSM Desktop. Nospecial restriction applies to the Memory Model file naming. However, it is strongly recommendedto follow an appropriate file naming convention containing information about the associatedMemory Device, the Memory Model category and the generation date (e.g.AOCSMEM_CONF_Model21_1999-10-25). This is required in order to ease the selection ofMemory Models in the OBSM applications.

3.5 Detailed Description of the Memory Model Files

In this section, the characteristics of the Memory Model files supported by the SCOS-2000 OBSMDesktop are described. The following applies:

Ø Each file will contain 4 lines of header (as specified in Section 3.5.1 below) followed by oneline per Memory Area definition belonging to the Memory Model. The structure of the MemoryArea definition records is specified in Section 3.5.2 below. There is no restriction in the numberof Memory Area definitions which can be contained in a Memory Model file.

Ø Each line is terminated by a carriage return.

Ø The field separator for Memory Area definition records is a Tabulation.


The following tables describe the structure of the Memory Model file records. They have to be readas follows:

Ø The ‘Size’ column specifies the maximum size that the line can take expressed in number ofASCII characters.

Ø The last column (‘M’) specifies whether the field is mandatory. Optional fields are allowed tobe left empty. However, the separation character (carriage return in case of header lines ortabulation in case of record fields) shall be present anyhow. If specified so in the ‘M’ column,optional fields which are left empty are automatically given a default value when loading theMemory Model file in the OBSM application.

Ø If a row is in italics, it means that the field is not used by the SCOS-2000 OBSM application.Typically, these fields contain data which may be required by mission specific applications orplaceholders for future extensions.



3.5.1 Structure of the Memory Model file header

The following table describes the structure of the Memory Model file header. One record per headerline.

Line Name Size Description M

1 Description 64 Free textual description of the Memory Model used for displaypurposes.

2 Category 1 Flag identifying the Memory Model category.

‘C’ – for Configuration tables i.e. Memory Models which canbe used for the generation of patch/dump command dataand thus are supposed to contain non-overlapping (but notnecessarily contiguous) Memory Area definitions.

‘S’ - for Symbolic Tables i.e. Memory Models which cannotbe used for the generation of command data. Typically,Symbolic Tables are used to provide a detailedinterpretation of a Memory Image. They are allowed tocontain ‘nested’ Memory Area definitions (i.e. areaswhich overlap but such that one area is completelycontained in another one).

M

3 MemoryDevice

8 Name of the Memory Device (MDF_NAME, see Section 2.6.1above) to which the model is associated. If specified, it is usedby the OBSM Desktop in order to check that the selectedMemory Model is associated to the same Memory Device asthe Memory Image to be processed.

4 Base 1 Integer number specifying the number of bytes which constitutethe addressing unit used in the definition of Memory Areas startaddress and length (see Section 3.5.2 below).

‘1’ – for bytes

‘2’ - for words

‘4’ - for 32 bit words.

Note: this field is only used by SCOS-2000 in order todetermine the compatibility between memory models andassociated memory images.

‘2’

3.5.2 Structure of the Memory Area Definition records

The following table describes the structure of the Memory Area definition records. One record perMemory Area contained in the Memory Model.

Field Name Size Description M



1 Name 48 Name of the Memory Area (also referred to as SymbolicAddress). Alphanumeric string uniquely identifying theMemory Area within this Memory Model.

M

2 Start address 8 Start address of the Memory Area specified in Hex and usingthe applicable addressing unit (see field Base in Section3.5.1 above).

M

3 Length 8 The length of the Memory Area specified in Hex and usingthe applicable addressing unit (see field Base in Section3.5.1 above).

M

4 Type 1 Type of the data contained in this area.

‘V’ - for Variable

‘D’ - for Data

‘O’ - for Object code

‘P’ – for Parameters.

This field is not used by the SCOS-2000 OBSM Desktop.

5 Patch 1 Flag identifying the patch category of this area.

‘P’ - for Patchable: the area has to be used for off-linecomparison and patched only if changed

‘N’ - for Not Patchable: the area shall not be patched

‘M’ - for Mandatory: the area has to be patched anyhow(even if not changed)

This field is used by the OBSM Desktop in order todetermine which areas have to be used for a model basedoff-line comparison and to provide filtering capabilities inthe Memory Image Comparison display. It is also used inorder to identify the areas to be covered by patch commands(see Table TBD below).

‘N’

6 Dump 1 Flag identifying the dump/monitor category of this area.

‘D’ - for Dumpable only: the area shall be dumped, used foroff-line comparison but not used for monitoring

‘N’ - for Not Dumpable: the area shall not be dumped, shallnot be used for monitoring nor for off-line comparison(unless it is marked as Patchable, see above)

‘M’ - for Dumpable and To be Monitored: the area shall bedumped and shall be used for both monitoring and off-line comparison.

This field is used by the OBSM Desktop in order todetermine which areas are to be used in a model basedmonitoring and off-line comparison and also to provide

‘N’



filtering capabilities in the Memory Image Monitoring andComparison displays. It is also used in order to identify theareas to be covered by dump commands (see Table TBDbelow).

7 Comment 64 Free textual comment describing this Memory Area.

This field is used by the OBSM Desktop for displaypurposes.

The following Table summarises the usage of the Patch and Dump attributes of memory areas forthe different processing options supported by the SCOS-2000 OBSM subsystem.

Processing Option Patch Attribute Dump Attribute CommentCOMPARISON ‘P’ or ‘M’ ‘D’ or ‘M’ All areas belonging to the memory

model are used for off-linecomparison unless they areidentified as Not Patchable and NotDumpable.

UPDATE N/A N/A Memory models are not used inorder to filter areas for the memoryimage updates based on dumptelemetry processing.

MONITOR N/A Only ‘M’ Only areas which are exp licitlyidentified as To be Monitored in theDump attribute are used for on-linecomparison (monitoring) against thereceived dump telemetry.

PATCH TCsGENERATION

‘P’ or ‘M’ N/A Areas which are Not Patchable shallnot be covered by Patch commands.

DUMP TCsGENERATION

N/A ‘D’ or ‘M’ Areas which are Not Dumpable shallnot be covered by Dump commands.

Table 1 – Summary of the usage of Patch/Dump attributes for the different processing options



4 MEMORY IMAGES IMPORT/EXPORT INTERFACE SPECIFICATION

This Section specifies the SCOS-2000 OBSM external interface supporting the import and theexport of Memory Images.


The import/export data consists of an ASCII file containing the data content of (a portion of) aspecified on-board memory device i.e. a Memory Image. Each ASCII file will contain all datarelevant to one single Memory Image. The same file structure is used in both directions i.e. whenimporting Memory Images into SCOS-2000 and when exporting them from SCOS-2000. Some fileheader information is automatically inserted in the export files. Image file header information isignored in the import files. The following subsections describe the typical operations involved inthe images import and export.

4.1.1 Memory Images Import

The Memory Image files are typically imported as follows:

Ø The image files are exported from the mission specific On-Board Software Development andValidation System into a mission specific format (typically containing some headerinformation followed by the image content data).

Ø These files are converted by a mission specific application into a format conforming to thestructure specified in this document.

Ø The actual import operations of the memory images into the SCOS-2000 OBSM depend onwhether the HFA or the FARC is used to store the images. This is described in the followingsections.

4.1.1.1 Images import ( storage into the FARC)

Ø The ASCII files conforming to the SCOS-2000 memory images structure are transferred into aconfigurable directory (see [RD-5]).

Ø The Memory Image files are imported one by one into the OBSM Desktop by selecting theproper file.

Ø The user is now able to save the image in the SCOS-2000 File Archive and make it availablefor later retrieval by specifying an Archive ID (identifying the images catalogues in which thisfile will appear) and the Memory Device to which the image is associate. The next applicableissue number or version are automatically assigned and used (along with the Archive ID andMemory Device) to uniquely identify the Memory Image inside SCOS-2000.



4.1.1.2 Images import (storage into history files)

Ø The ASCII files conforming to the SCOS-2000 memory images structure are transferred intothe inTray directory of the SCOS-2000 FARC (see [RD-3]).

Ø The Memory Image files are imported one by one into the SCOS-2000 FARC. In case a filewith the same name already exists, a new version of the Memory Image is automaticallycreated by the FARC.

Ø The user is now able to select a Memory Image file by specifying its name and version numberand make it available to the SCOS-2000 OBSM Desktop for further processing by saving itinto the SCOS-2000 history files with its own image number and version.

4.1.2 Memory Images Export

The Memory Image files are typically exported as follows:

Ø Any type of image (Reference, Working or On-Going, see [AD-1]) can be selected andexported on user request.

Ø An ASCII file with a structure conforming to Section 4.6 below is generated with a defaultname and located into the directory specified by the user (the default export directory isconfigurable).

Ø These files are then manipulated and transferred as required by mission specific requirements.

4.2 Scope

This ICD only covers the definition of the Memory Image files as expected and exported by theSCOS-2000 OBSM Desktop. It does not cover the generation and transfer of the import files intothe appropriate location. It does not cover the transfer of the export files to their final destination.


The Memory Image import files will have to respect the exact structure described in the presentdocument. The file structure does not impose any constraint in the memory areas which can becovered by a Memory Image. The same file structure is suitable for the import/export of completememory images (i.e. files defining the complete content of a memory device) or partial memoryimages (i.e. files defining only a portion of the areas covered by a memory device). However, eachfile will be handled as an independent image within SCOS-2000.

This ICD does not impose any specific constraint in the way that the Memory Image files aregenerated and maintained in the mission specific systems.

Remark: only limited consistency checks will be applied by the OBSM desktop at Memory Imageimport time. It is the responsibility of the mission specific generation and transfer systems/procedure to ensure consistency and completeness of the data.



4.4 File Naming Conventions

No special restriction applies to the file naming of Memory Image import files. A completelymission specific naming convention can be adopted.

The Memory Image export files are automatically given a default filename based on aconcatenation of the following image attributes followed by the .IMG extension:

• Name of the associated Memory Device• Image type (e.g. PATCH, DUMP, REFERENCE)• Image ID (issue number and version)• Image saving time

Eg:

Associated device: PROCAImage ID: 1001005Image Type: ReferenceImage timestamp: 2000.202.13.28.42

The default filename would become:

PROCA_REF_1001_005_2000202132842.IMG

Note that the default name of the exported Memory Image files can be modified by the user prior toexecution of the export request.

4.5 Detailed Description of the Memory Image Import Files

In this section, the characteristics of the Memory Image import files supported by the SCOS-2000OBSM Desktop are described. The following applies:

Ø Each file consists of an optional line explicitly specifying the applicable memory data unit sizefollowed by a variable number of lines each containing one memory data record.

Remark: header lines preceding the memory data unit line and the memory data records aredisregarded by the SCOS-2000 OBSM Memory Image importer (with the exceptions listed below).This allows missions to leave their own header information or to directly re-import images whichhave been exported from the SCOS-2000 OBSM. The only restriction is that header lines shall notstart with the strings ‘START=’ or ‘UNIT=’ and shall all precede the actual data records.

Ø Each data record shall contain the memory content of a variable number of contiguous datawords starting at a specified address.

Ø Lines shall be sorted in ascending address order.



Ø If not explicitly specified in the image import file, a default memory data unit (i.e. bytes, 16-bitwords or 32-bit words) is adopted by SCOS-2000 to interpret the memory image files. Thedefault memory unit is configurable on a global basis.

Remark: a mission specific extension of the SCOS-2000 Memory Image import software is requiredin case the addressing unit may be different across Memory Devices of the same mission. Typically,the addressing unit should be specified as part of the mission specific header of the Memory Imagefiles.

Ø The maximum number of memory data words which can be specified in a line is sixteen.

Ø Each line is terminated by a carriage return.


The applicable memory data unit size can be explicitly specified as part of memory image files tobe imported by introducing a line starting with the string ‘UNIT=’ just before the data records. Theunit size is specified as the number of bytes in an address i.e. 1 for bytes, 2 for 16-bit words and 4for 32-bit words. The applicable data unit size is always explicitly specified in the exported memoryimage files.

In addition, the default name of the memory device to which the image belongs and the defaultimage short description can also be optionally specified as part of the image header. This can beachieved by introducing in the image header lines starting with the strings:

Ø ‘DEVICE=’ followed by the device name

Ø ‘DESCRIPTION=’ followed by the image short description.

The following table describes the structure of the Memory Image data records. Each record shallmandatorily contain the three fields described below separated by a comma (‘,’). The actual fielddata are always preceded by an ASCII string which has been inserted in order to improve thehuman readability of the file content.

Note that the ‘Size’ column in the following table specifies the maximum size that the field can takeexpressed in number of ASCII characters. This includes the ASCII string preceding the actual data.

Field Name Size Description

1 Start address 14 This field shall contain the string ‘START=’ immediatelyfollowed by the start address of the memory data being defined inthis line. The start address shall be expressed using a variablenumber of Hex digits (up to 8).

Note: in the Memory Image export files the start address is‘padded’ with leading zeros such that it will always be specifiedas an 8-digit Hex value.

2 Number ofWords

7 This field shall contain the string ‘COUNT=’ immediatelyfollowed by the number of memory data units (i.e. bytes, wordsor 32-bit words) being defined in this line. The number of data



units shall be expressed using a single Hex digit (it is possible tospecify up to 16 data units per line).

Note: the size of the memory data unit is driven by the imagememory unit (see above).

3 Memory Data 69 This field shall contain the string ‘DATA=’ immediately followedby the specified number of memory data units (see field Numberof Words above). Each memory data unit shall be expressed as a2N-digit Hex value, where N depends on the applicable memorydata unit size (i.e. 1 for bytes, 2 for 16-bit words and 4 for 32-bitwords). There shall be no separation between subsequent datawords.

In the following, some examples of Memory Image files are given.

Example 1.

This is a memory image for a device based on 16-bit words.UNIT=2START=000000,COUNT=2,DATA=12345678START=00000010,COUNT=3, DATA=123456789ABC

In this case the applicable memory unit is a 16-bit word, thus this corresponds to the followingpatch data.

ADDRESS DATA00000000 123400000001 567800000010 123400000011 567800000012 9ABC

Example 2.

This is a memory image for a device based on bytes.UNIT=1START=00000,COUNT=4,DATA=12345678START=00010,COUNT=6, DATA=123456789ABC

In this case the applicable addressing unit is a byte, thus this corresponds to the following patchdata.

ADDRESS DATA00000000 1200000001 3400000002 56



00000003 7800000010 1200000011 3400000012 5600000013 7800000014 9A00000015 BC

Example 3.

This is a memory image for a device based on 16-bit wordsSTART=000,COUNT=2,DATA=12345678START=00000010,COUNT=3, DATA=123456789ABC

In this case the applicable addressing unit is not explicitly specified as part of the Memory Imagefile. The default memory unit is thus used. In case the MISCConfig variableBYTES_IN_ADDRESS is set to 2 (the default memory unit is a 16-bit word), this corresponds tothe following patch data.

ADDRESS DATA00000000 123400000001 567800000010 123400000011 567800000012 9ABC

In case the MISCConfig variable BYTES_IN_ADDRESS is set to 1 (the default memory unit is abyte), there will be an error in reading the data above, because the COUNT value does not matchwith the memory data. There would instead be no error in reading the following data file,corresponding to the following patch data.

This is a memory image for a device based on bytes.START=000,COUNT=4,DATA=12345678START=00000010,COUNT=6, DATA=123456789ABC

ADDRESS DATA00000000 1200000001 3400000002 5600000003 7800000010 1200000011 3400000012 5600000013 78



00000014 9A00000015 BC

4.6 Detailed Description of the Memory Image Export Files

In this section, the characteristics of the Memory Image export files supported by the SCOS-2000OBSM Desktop are described. Each export file consists of some header information followed byexactly the same file structure described in Section 4.5 above for Memory Image import files(including the line specifying the applicable memory data unit size followed by a variable numberof memory data records).

The header information included in the SCOS-2000 Memory Image export files consists of thefollowing lines:

ID=image release number in decimal (e.g. 2)VERSION=image version number in decimal (e.g. 4)TYPE=image type (e.g. reference, dump, patch, edit)DESCRIPTION=image short descriptionSOURCE=name of the file from which the image was originally imported (if any)CREATIONDATE=image creation time in the format yyyy- mm-ddThh:mm:ss:mcs (withmicroseconds on 6 digits)MODEL=memory model associated to the imageMODELVER=release and issue numbers of the memory model (e.g. 2.3)DEVICE=name of the memory device to which the image is associatedSTARTADDR=address of the first memory data unit in the image (in Hex)ENDADDR=address of the last memory data unit in the image (in Hex)LENGTH=number of memory data units contained in the imageCHECKSUM=checksum of the image (in Hex)UNIT=number of bytes contained in each memory data unit (same as for import images).



Annex 1: List of implemented changes

1. DCR-097: Convert the text of the field MDF_TYPE into italics as it is not used by the SCOS-2000 OBSM.

2. DCR-098: Update the image export header to reflect the real implementation.3. DCR-157: Modify the section about images import in order to introduce the ability to read the

device name and image description from the imported header.4. Add an attribute (MDF_BASE) of Memory Devices to specify the applicable addressing data

unit size.5. Add one option to the Dump field of Memory Area Definitions to specify its ‘Monitorability’

and modify the description of the Patch field accordingly (Patchable areas are to be used for off-line comparison).

6. Modify the description of the Memory Models import to state that models will be imported intothe FARC via the OBSM Desktop (this is required in order to create and maintain a MemoryModels catalogue similar to the Memory Images catalogue).