SCOS-2000 OBSM External Interfaces Control Document

Transcription

1 ESA/OPS-GIC SCOS-2000 OBSM External Interfaces Control Document Document Reference: EGOS-MCS-S2K-ICD-0014 Document Status: Version 1.4 Prepared By: SCOS-2000 Team

2 SCOS-2000 OBSM External Interfaces ICD Page: 1 0 SERVICES 0.1 Approval sheet Name and Function Date Signature Prepared by : SCOS-2000 Team Verified by : Approved by : Authorised by: SCOS-2000 Management SCOS-2000 TOS-GIC Management G. Montroni, TOS-GIC M.Pecchioli, OPS-GIC Management R. Southworth, OPS-OFO See Acceptance Certificate reference: OPS- GIC-R_S2K-4.0_ See Acceptance Certificate reference: OPS- GIC-R_S2K-4.0_ See Acceptance Certificate reference: OPS- GIC-R_S2K-4.0_ COPYRIGHT EUROPEAN SPACE AGENCY, The copyright of this document is vested in the European Space Agency. This document may only be reproduced in whole or in part, stored in a retrieval system, transmitted in any form, or by any means electronic, mechanical, photocopying, or otherwise, with the prior permission of the European Space Agency.

3 SCOS-2000 OBSM External Interfaces ICD Page: 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 Images import/export files. 1 2 Aug 23, 2000 Addition of the header in the exported image files. Implementation of the approved DCRs listed in Annex Jun 11, 2001 Implementation of the non-editorial changes listed in Annex /09/2004 Updated for SCOS-2000 release 4.0. Document reference changed. Maximum number of memory data unit is 15 instead of 16. The implementation of the non-editorial changes listed in Annex 1.

4 SCOS-2000 OBSM External Interfaces ICD Page: 3 Abstract This document is the interface control document of the file based external interfaces supported by the SCOS-2000 OBSM applications. It covers the import of memory devices and memory models definitions as well as the import and export of memory images. Data in the suitable format are typically generated by off-line system of any client mission using SCOS This document only covers the generic portion of the static data which are relevant to functions supported by the SCOS-2000 OBSM subsystem. Mission specific extensions are possible.

5 SCOS-2000 OBSM External Interfaces ICD Page: 4 Table of Contents 0 SERVICES Approval sheet Document Status Sheet Introduction Purpose Scope Overview Definitions, Acronyms and Abbreviations References Applicable Documents Reference Documents Memory Devices Import Interface Specification General Description Scope Assumptions and Constraints Location and Naming Convention of the ASCII Files Structure of the ASCII Files Detailed Definition of the Table Records Structure Memory Devices File: mdf On-Board Processors Definition File: pdf Device Connection File: dcf Memory Models Import Interface Specification General Description Scope Assumptions and Constraints File Naming Convention Detailed Description of the Memory Model Files Structure of the Memory Model file header Structure of the Memory Area Definition records Memory Images Import/Export Interface Specification General Description Memory Images Import Memory Images Export Scope Assumptions and Constraints... 20

6 SCOS-2000 OBSM External Interfaces ICD Page: File Naming Conventions Detailed Description of the Memory Image Import Files Detailed Description of the Memory Image Export Files Annex 1: List of implemented changes... 26

7 SCOS-2000 OBSM External Interfaces ICD Page: 6 1 INTRODUCTION 1.1 Purpose This document is the interface control document of the file based external interfaces supported by the SCOS-2000 OBSM applications. Data in the suitable format are typically generated by off-line systems of the client missions using SCOS 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-time database in the SCOS-2 OBSM implementation and thus their import was covered by the SCOS-2 MIB ICD. 1.3 Overview This document is organised as follows: Section 1: Section 2: Section 3: Section 4: Introduction Memory Devices Import Interface Specification Memory Models Import Interface Specification 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 is available in [RD-1].

8 SCOS-2000 OBSM External Interfaces ICD Page: References Applicable Documents Doc. Reference Title AD-1 SRD-0005 SCOS-2000 OBSM SRD Reference Documents Doc. Reference Title RD-1 GLO-0001 SCOS-2000 Glossary, Definitions and Acronyms RD-2 ICD-0001 SCOS-2000 Database Import ICD RD-3 SUM-0021 SCOS-2000 FARC Software User Manual RD-4 ESA PSS Packet Utilisation Standard RD-5 SUM-0002 SCOS-2000 Configuration and Installation Guide

9 SCOS-2000 OBSM External Interfaces ICD Page: 8 2 MEMORY DEVICES IMPORT INTERFACE SPECIFICATION This Section specifies the SCOS-2000 OBSM external interface supporting the import of static data describing 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 Devices and Memory Processors. One ASCII file will contain all data belonging to one table (e.g. the mdf file 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 this document. These ASCII files are transferred into a specific directory accessible from the workstation running 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 OBSM Desktop. 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. Each ASCII 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 and maintained in the off-line database system (mission specific). Remark: only limited consistency checks are applied by the OBSM desktop at data loading time. It is the responsibility of the off-line system to ensure full 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 accessible by its own SCOS-2000 OBSM system. The name and path of the directories where the ASCII files have to be located is configurable by client missions in the MISCConfig file.

10 SCOS-2000 OBSM External Interfaces ICD Page: 9 Each ASCII file shall be given the name of the corresponding table (see Section 2.6 below) in lower case 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 is described. 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 to be 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 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 of whether 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 or unsigned) are allowed to be specified for field of type Number. Field of type Char allow any alphanumeric ASCII characters i.e. A-Z and 0-9. Underscore, plus/minus, dot and dash characters are also allowed. Other ASCII characters shall be avoided. Also note that the format of a specific field can be further constrained by its nature e.g. a SCOS-2000 TM Packet ID can only be an unsigned integer number greater than zero. Remark: It is recommended not to use space characters within names i.e. within the alphanumeric strings used for unique identification of a database item (e.g. a parameter name). Further, the uniqueness 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 allowed to 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 by the SCOS-2000 OBSM Desktop for any processing. Typically, these fields/tables are left over from previous implementations. If a row/table is in italics, it means that the field/table is imported but not directly used by the SCOS-2000 OBSM application. Typically, these fields contain data which may be required by mission specific applications (e.g. the patch/dump command generator) or which are placeholders for mission specific extensions (e.g. handling of on-board processors).

11 SCOS-2000 OBSM External Interfaces ICD Page: 10 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 unused fields which are left Null shall anyway be considered in that the field separator character corresponding 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 the SCOS-2000 OBSM Desktop). dcf: device connection file, defining the connections between the on-board processors and the memory devices (not used by the SCOS-2000 OBSM Desktop) Memory Devices File: mdf The mdf table defines the attributes of the on-board memory devices. One record per memory device. Fi.Nr Field name Field Type Description Ma 1 MDF_NAME Char(8) Name of the memory device. An alphanumeric string uniquely identifying the memory device. M 2 MDF_DESC Char(20) A textual description of the memory device used for display purposes. 3 MDF_DPID Number(10) SCOS-2000 Packet ID of the associated dump packet. An unsigned integer number matching with the PID_SPID (see [RD-2]) of the TM packet containing the dump data to be processed in order to maintain the memory 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 is associated with. An alphanumeric string matching with the CCF_CNAME (see [RD-2]) of the command to be used in order to patch this memory device. 7 MDF_DUMP Char(8) Name of the dump command that the memory device is associated with.

12 SCOS-2000 OBSM External Interfaces ICD Page: 11 Fi.Nr Field name Field Type Description Ma An alphanumeric string matching with the CCF_CNAME (see [RD-2]) of the command to be used in order to dump this memory device. 8 MDF_SPID Number(10) SCOS-2000 Packet ID of the memory packet associated to this memory device. Note: this field is only applicable in case the SCOS history files are used to archive memory images (i.e. in case the MISCconfig variable OBSM_IMAGE_ID_FILE is not set to FARC manager ). In this case, it is used by the OBSM desktop to identify the history file to be used to store and retrieve the reference images associated to this memory device. 9 MDF_TYPE Number(2) Identifier of the memory device type. It can be used by the client missions in order to identify the specific processing to be applied to images belonging to this memory device (e.g. algorithm to be applied for the calculation of checksum, applicable structure for the patch and dump commands to be generated and for the 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 used as the algorithm used to calculate the checksum for the images associated to any memory device is the Cyclic Redundancy Code (see the Packet Utilisation Standard, [RD-4] Appendix A.2). 10 MDF_BASE Number(1) Integer number specifying the number of bytes which constitute 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 in order to determine the compatibility between memory devices and associated memory images On-Board Processors Definition File: pdf The pdf table defines the attributes of the on-board processors. One record per on-board processor. It is not used by SCOS-2000 OBSM.

13 SCOS-2000 OBSM External Interfaces ICD Page: 12 Fi.Nr Field name Field Type Description M 1 PDF_NAME Char(8) Name of the processor. M An alphanumeric string uniquely identifying the onboard processor. 2 PDF_DESC Char(20) Textual description of the on-board processor 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-board processors. It is not used by SCOS-2000 OBSM. Fi. Nr Field name Field Type Description 1 DCF_PROC Char(8) Name of the processor (PDF_NAME) that this connection definition is to be applied to. 2 DCF_DEVICE Char(8) Name of the memory device (MDF_NAME) that this connection definition is to be applied to. 3 DCF_ACCESS Char(1) Flag identifying the type of connection between the device and the processor. C - for currently connected A - for accessible. M M M

14 SCOS-2000 OBSM External Interfaces ICD Page: 13 3 MEMORY MODELS IMPORT INTERFACE SPECIFICATION This Section specifies the SCOS-2000 OBSM external interface supporting the import of static data describing the Memory Models. 3.1 General Description The data source consists of an ASCII file describing the characteristics of a Memory Model. Each ASCII 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 files conforming 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 the proper file. The user is now able to save the model in the SCOS-2000 File Archive and make it available for later retrieval by specifying its name, an Archive ID (identifying the catalogue in which this file will appear) and the Memory Device to which the model is associated. In case another model with the same name is already present in the selected Archive, the next applicable version number is automatically assigned and used (along with the Archive ID and model name) to uniquely identify the Memory Model inside SCOS Scope This ICD only covers the definition of the Memory Model files as expected by the SCOS-2000 OBSM Desktop. It does not cover the generation and transfer of these files into the appropriate location. 3.3 Assumptions and Constraints 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 are generated and maintained in the off-line system (mission specific). Remark: only limited consistency checks will be applied by the OBSM desktop at Memory Model loading time. It is the responsibility of the off-line system to ensure consistency of the data. Only the following checks are applied by the OBSM desktop at data loading time: Config Tables: Nested areas are valid, overlapping areas are invalid. Symbol Tables: Nested areas and overlapping areas are invalid. Model area attributes are ignored for Symbol Tables by the OBSM Desktop.

15 SCOS-2000 OBSM External Interfaces ICD Page: File Naming Convention The file name will determine the Memory Model name as displayed in the OBSM Desktop. No special restriction applies to the Memory Model file naming. However, it is strongly recommended to follow an appropriate file naming convention containing information about the associated Memory Device, the Memory Model category and the generation date (e.g. AOCSMEM_CONF_Model21_ ). This is required in order to ease the selection of Memory 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 OBSM Desktop are described. The following applies: Each file will contain 4 lines of header (as specified in Section below) followed by one line per Memory Area definition belonging to the Memory Model. The structure of the Memory Area definition records is specified in Section below. There is no restriction in the number of 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 end-of-file convention is EOF. The following tables describe the structure of the Memory Model file records. They have to be read as follows: The Size column specifies the maximum size that the line can take expressed in number of ASCII characters. The last column ( M ) specifies whether the field is mandatory. Optional fields are allowed to be left empty. However, the separation character (carriage return in case of header lines or tabulation 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 the Memory 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 or placeholders for future extensions.

16 SCOS-2000 OBSM External Interfaces ICD Page: Structure of the Memory Model file header The following table describes the structure of the Memory Model file header. One record per header line. Line Name Size Description M 1 Description 64 Free textual description of the Memory Model used for display purposes. 2 Category 1 Flag identifying the Memory Model category. C for Configuration tables i.e. Memory Models which can be used for the generation of patch/dump command data and thus are supposed to contain non-overlapping (but not necessarily contiguous) Memory Area definitions. S - for Symbolic Tables i.e. Memory Models which cannot be used for the generation of command data. Typically, Symbolic Tables are used to provide a detailed interpretation of a Memory Image. They are allowed to contain nested Memory Area definitions (i.e. areas which overlap but such that one area is completely contained in another one). 3 Memory Device 8 Name of the Memory Device (MDF_NAME, see Section above) to which the model is associated. If specified, it is used by the OBSM Desktop in order to check that the selected Memory Model is associated to the same Memory Device as the Memory Image to be processed. 4 Base 1 Integer number specifying the number of bytes which constitute the addressing unit used in the definition of Memory Areas start address and length (see Section below). 1 for bytes 2 - for words 4 - for 32 bit words. Note: this field is only used by SCOS-2000 in order to determine the compatibility between memory models and associated memory images. M Structure of the Memory Area Definition records The following table describes the structure of the Memory Area definition records. One record per Memory Area contained in the Memory Model. Field Name Size Description M

17 SCOS-2000 OBSM External Interfaces ICD Page: 16 1 Name 48 Name of the Memory Area (also referred to as Symbolic Address). Alphanumeric string uniquely identifying the Memory Area within this Memory Model. 2 Start address 8 Start address of the Memory Area specified in Hex and using the applicable addressing unit (see field Base in Section above). 3 Length 8 The length of the Memory Area specified in Hex and using the applicable addressing unit (see field Base in Section above). 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-line comparison 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 to determine which areas have to be used for a model based off-line comparison and to provide filtering capabilities in the Memory Image Comparison display. It is also used in order to identify the areas to be covered by patch commands (see the table below). M M M N

18 SCOS-2000 OBSM External Interfaces ICD Page: 17 6 Dump 1 Flag identifying the dump/monitor category of this area. D - for Dumpable only: the area shall be dumped, used for off-line comparison but not used for monitoring N - for Not Dumpable: the area shall not be dumped, shall not 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 be dumped and shall be used for both monitoring and offline comparison. This field is used by the OBSM Desktop in order to determine which areas are to be used in a model based monitoring and off-line comparison and also to provide filtering capabilities in the Memory Image Monitoring and Comparison displays. It is also used in order to identify the areas to be covered by dump commands (see the table below). 7 Comment 64 Free textual comment describing this Memory Area. This field is used by the OBSM Desktop for display purposes. N The following Table summarises the usage of the Patch and Dump attributes of memory areas for the different processing options supported by the SCOS-2000 OBSM subsystem. Processing Option Patch Attribute Dump Attribute Comment COMPARISON P or M D or M All areas belonging to the memory model are used for off-line comparison unless they are identified as Not Patchable and Not Dumpable. UPDATE N/A N/A Memory models are not used in order to filter areas for the memory image updates based on dump telemetry processing. MONITOR N/A Only M Only areas which are explicitly identified as To be Monitored in the Dump attribute are used for on-line comparison (monitoring) against the received dump telemetry. PATCH TCs P or M N/A Areas which are Not Patchable shall GENERATION DUMP TCs GENERATION not be covered by Patch commands. N/A D or M Areas which are Not Dumpable shall not be covered by Dump commands. Table 1 Summary of the usage of Patch/Dump attributes for the different processing options

19 SCOS-2000 OBSM External Interfaces ICD Page: 18

20 SCOS-2000 OBSM External Interfaces ICD Page: 19 4 MEMORY IMAGES IMPORT/EXPORT INTERFACE SPECIFICATION This Section specifies the SCOS-2000 OBSM external interface supporting the import and the export of Memory Images. 4.1 General Description The import/export data consists of an ASCII file containing the data content of (a portion of) a specified on-board memory device i.e. a Memory Image. Each ASCII file will contain all data relevant to one single Memory Image. The same file structure is used in both directions i.e. when importing Memory Images into SCOS-2000 and when exporting them from SCOS Some file header information is automatically inserted in the export files. Image file header information is ignored in the import files. The following subsections describe the typical operations involved in the images import and export 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 and Validation System into a mission specific format (typically containing some header information followed by the image content data). These files are converted by a mission specific application into a format conforming to the structure specified in this document. The actual import operations of the memory images into the SCOS-2000 OBSM depend on whether the HFA or the FARC is used to store the images. This is described in the following sections Images import ( storage into the FARC) The ASCII files conforming to the SCOS-2000 memory images structure are transferred into a configurable directory (see [RD-5]). The Memory Image files are imported one by one into the OBSM Desktop by selecting the proper file. The user is now able to save the image in the SCOS-2000 File Archive and make it available for later retrieval by specifying an Archive ID (identifying the images catalogues in which this file will appear) and the Memory Device to which the image is associate. The next applicable issue number or version are automatically assigned and used (along with the Archive ID and Memory Device) to uniquely identify the Memory Image inside SCOS-2000.

21 SCOS-2000 OBSM External Interfaces ICD Page: Images import (storage into history files) The ASCII files conforming to the SCOS-2000 memory images structure are transferred into the 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 file with the same name already exists, a new version of the Memory Image is automatically created by the FARC. The user is now able to select a Memory Image file by specifying its name and version number and make it available to the SCOS-2000 OBSM Desktop for further processing by saving it into the SCOS-2000 history files with its own image number and version 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 and exported on user request. An ASCII file with a structure conforming to Section 4.6 below is generated with a default name and located into the directory specified by the user (the default export directory is configurable). 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 the SCOS-2000 OBSM Desktop. It does not cover the generation and transfer of the import files into the appropriate location. It does not cover the transfer of the export files to their final destination. 4.3 Assumptions and Constraints The Memory Image import files will have to respect the exact structure described in the present document. The file structure does not impose any constraint in the memory areas which can be covered by a Memory Image. The same file structure is suitable for the import/export of complete memory images (i.e. files defining the complete content of a memory device) or partial memory images (i.e. files defining only a portion of the areas covered by a memory device). However, each file will be handled as an independent image within SCOS This ICD does not impose any specific constraint in the way that the Memory Image files are generated and maintained in the mission specific systems. Remark: only limited consistency checks will be applied by the OBSM desktop at Memory Image import time. It is the responsibility of the mission specific generation and transfer systems/ procedure to ensure consistency and completeness of the data.

22 SCOS-2000 OBSM External Interfaces ICD Page: File Naming Conventions No special restriction applies to the file naming of Memory Image import files. A completely mission specific naming convention can be adopted. The Memory Image export files are automatically given a default filename based on a concatenation 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: PROCA Image ID: Image Type: Reference Image timestamp: The default filename would become: PROCA_REF_1001_005_ IMG Note that the default name of the exported Memory Image files can be modified by the user prior to execution 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-2000 OBSM Desktop are described. The following applies: Each file consists of an optional line explicitly specifying the applicable memory data unit size followed 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 are disregarded 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 which have been exported from the SCOS-2000 OBSM. The only restriction is that header lines shall not start 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 data words starting at a specified address. Lines shall be sorted in ascending address order.

23 SCOS-2000 OBSM External Interfaces ICD Page: 22 If not explicitly specified in the image import file, a default memory data unit (i.e. bytes, 16-bit words or 32-bit words) is adopted by SCOS-2000 to interpret the memory image files. The default memory unit is configurable on a global basis. The characters allowed in the header fields processed by the Import function are A-Za-z0-9,_=-!@#$%^&*()~`':;" /?<>[]{}\. An image file can contain 0 data records. This is used to store empty images. Remark: a mission specific extension of the SCOS-2000 Memory Image import software is required in 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 Image files. The maximum number of memory data units which can be specified in a line is fifteen. Each line is terminated by a carriage return. The end-of-file convention is EOF. The applicable memory data unit size can be explicitly specified as part of memory image files to be imported by introducing a line starting with the string UNIT= just before the data records. The unit size is specified as the number of bytes in an address i.e. 1 for bytes, 2 for 16-bit words and 4 for 32-bit words. The applicable data unit size is always explicitly specified in the exported memory image files. In addition, the default name of the memory device to which the image belongs and the default image short description can also be optionally specified as part of the image header. This can be achieved 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. It is mandatory that each record contain the three fields described below separated by a comma (, ). The actual field data are always preceded by an ASCII string, which has been inserted in order to improve the human readability of the file content. Note that the Size column in the following table specifies the maximum size that the field can take expressed in number of ASCII characters. This includes the ASCII string preceding the actual data. Field Name Size Description

24 SCOS-2000 OBSM External Interfaces ICD Page: 23 1 Start address 14 This field shall contain the string START= immediately followed by the start address of the memory data being defined in this line. The start address shall be expressed using a variable number 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 specified as an 8-digit Hex value. 2 Number of memory data units 7 This field shall contain the string COUNT= immediately followed by the number of memory data units (i.e. bytes, words or 32-bit words) being defined in this line. The number of data units shall be expressed using a single Hex digit (it is possible to specify up to 15 data units per line). Note: the size of the memory data unit is driven by the image memory unit (see above). 3 Memory Data 69 This field shall contain the string DATA= immediately followed by the specified number of memory data units (see field Number of Words above). Each memory data unit shall be expressed as a 2N-digit Hex value, where N depends on the applicable memory data unit size (i.e. 1 for bytes, 2 for 16-bit words and 4 for 32-bit words). There shall be no separation between subsequent data words. 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=2 START=000000,COUNT=2,DATA= START= ,COUNT=3, DATA= ABC In this case the applicable memory unit is a 16-bit word, thus this corresponds to the following patch data. ADDRESS DATA ABC Example 2. This is a memory image for a device based on bytes.

25 SCOS-2000 OBSM External Interfaces ICD Page: 24 UNIT=1 START=00000,COUNT=4,DATA= START=00010,COUNT=6, DATA= ABC In this case the applicable addressing unit is a byte, thus this corresponds to the following patch data. ADDRESS DATA A BC Example 3. This is a memory image for a device based on 16-bit words START=000,COUNT=2,DATA= START= ,COUNT=3, DATA= ABC In this case the applicable addressing unit is not explicitly specified as part of the Memory Image file. The default memory unit is thus used. In case the MISCConfig variable BYTES_IN_ADDRESS is set to 2 (the default memory unit is a 16-bit word), this corresponds to the following patch data. ADDRESS DATA ABC In case the MISCConfig variable BYTES_IN_ADDRESS is set to 1 (the default memory unit is a byte), there will be an error in reading the data above, because the COUNT value does not match with 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= START= ,COUNT=6, DATA= ABC

26 SCOS-2000 OBSM External Interfaces ICD Page: 25 ADDRESS DATA A 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-2000 OBSM Desktop are described. Each export file consists of some header information followed by exactly 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 number of memory data records). The header information included in the SCOS-2000 Memory Image export files consists of the following 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 description SOURCE=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 (with microseconds on 6 digits) MODEL=memory model associated to the image MODELVER=release and issue numbers of the memory model (e.g. 2.3) DEVICE=name of the memory device to which the image is associated STARTADDR=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 image CHECKSUM=checksum of the image (in Hex) UNIT=number of bytes contained in each memory data unit (same as for import images).

27 SCOS-2000 OBSM External Interfaces ICD Page: 26 Annex 1: List of implemented changes Changes implemented in version DCR-097: Convert the text of the field MDF_TYPE into italics as it is not used by the SCOS 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 offline comparison). 6. Modify the description of the Memory Models import to state that models will be imported into the FARC via the OBSM Desktop (this is required in order to create and maintain a Memory Models catalogue similar to the Memory Images catalogue). Changes implemented in version The maximum number of memory data units (keyword COUNT) is 15 instead of 16.