Recommendation for Space Data System Practices
Download 2.26 Mb.
|
- Navigate this page:
- StructurAL Elements Standard Format
- Standard ASCII Representation
- Identifiers and Abbreviations for Attributes
- Table C 11: Identifiers and Abbreviations for Attributes
- Syntax of the Standard ASCII Representation
- Simple Component Model (Normative) Introduction
Introduction Purpose and Scope This annex provides a definition of the service instance identifier to be used by the SLE API components for version 1 of the SLE services RAF, RCF, and CLTU. This specification was used by implementations preceding this Recommended Practice, because the required definitions were not provided by version 1 of the CCSDS Recommended Standards for the SLE services RAF, RCF and CLTU (references [ C 1], [ C 2], and [ C 3]). For later versions of the SLE services RAF, RCF, and CLTU and for all other SLE service types, the specification in the CCSDS Recommended Standards for SLE transfer services shall be used. The service instance identifier is a distinguished name as defined by reference [17], which is constructed according to the containment relationships of the managed objects in the CCSDS Recommended Standard for SLE service management. The attributes used in the service instance identifier, are the naming attributes of the managed objects. The values of the naming attributes are printable strings. The SLE API only checks the validity of the attribute identifiers and does not check conformance to the containment relationships. These must be observed when the service instance identifier is defined. Therefore this annex only provides a list of defined attributes and does not cover the containment relationships. The names of the managed objects and the names of their naming attributes are provided for information only. They are not processed by the API. The API supports two formats for the service instance identifier:
Conversion between the two formats is supported.
[C1] Space Link Extension—Return All Frames Service Specification. Issue 1.7. Proposed Draft Recommendation for Space Data System Standards (Draft Red Book), CCSDS 911.1-R-1.7. n.p.: n.p., September 1999. [C2] Space Link Extension—Return Virtual Channel Frames Service Specification. Issue 1.7. Proposed Draft Recommendation for Space Data System Standards (Draft Red Book), CCSDS 911.2-R-1.7. n.p.: n.p., September 1999. [C3] Space Link Extension—Forward CLTU Service. Issue 1.99h. Proposed Draft Recommendation for Space Data System Standards (Draft Red Book), CCSDS 912.1-R-1.99h. n.p.: n.p., February 2000.
The standard format consists of a sequence of ‘attribute value assertions’, i.e., pairs of an attribute identifier and an attribute value. The attribute identifier is an object identifier as defined by ASN.1 (reference [15]). The detailed binary format is not defined by this Recommended Practice. It is implemented by the component SLE Utilities, which provides access to the format as defined by the interface ISLE_SII in annex A.1.1.1.1.1.1.1 of this Recommended Practice. The standard ASCII representation makes use of human readable abbreviations for the attribute identifiers as defined in 1. The syntax of this representation is defined in 2.
The Object IDentifiers (OID) and human readable abbreviations for attributes used in the service instance identifier are specified by the following table. References to the managed objects and the type names for attributes are provided for information only. The object identifiers of the attributes differ only in the trailing component, which is identified in the table. The leading part of the object identifier is defined as: {iso (1) identified-organization (2) ccsds (0) sle-services (9) service-management (5) attributes (2)} This definition assumes that CCSDS will be registered by ISO directly below the node ‘identified organization’. The number 0 is an arbitrary placeholder for the value that will be assigned to CCSDS. As an example, the object identifier for the naming attribute of the managed object ‘Forward CLTU Transfer Service Provided’ (f cltu ts-p-mo-id) contains the following sequence of numbers: 1 2 0 9 5 2 7 Table C 11: Identifiers and Abbreviations for Attributes
The syntax of the standard ASCII representation is defined by the following grammar: [‘.’ In addition, the following rules are applied:
Example: The following example presents the identifier of a RAF service instance. The attribute values are arbitrary. sagr=ESA-JPL-INTEGRAL.spack=routine-123.rsl=DL.rsl-fg=DL.raf=pass-21
The SLE API is based on the concept of integrating independently developed components with the SLE application. This concept has important advantages. For instance, it allows an organization offering SLE services to provide an API Proxy component to the users for integration into SLE user applications. In order to simplify integration of independently developed components by a third party, dependencies between the components must be minimized. In addition, the need for delivery of source code and of the required building procedures should be avoided as far as possible. Finally, there must be some means of customizing a component for the specific environment in which it shall be deployed. These objectives are supported by component models. However, at the time this Recommended Practice was developed, component systems were just emerging and a commonly accepted, platform-independent scheme was not available. Of the existing models, the Component Object Model (COM) developed by Microsoft (see reference [ J 26]) was the only one that could be directly used with the C++ language. However, COM requires a special run-time library and the presence of the COM Registry. Dependency on a special run-time environment that might not be readily available on all platforms was not considered acceptable for the SLE API. Therefore this Recommended Practice defines a very basic component model specifically for the SLE API. For this model it adopts a limited set of design patterns and conventions from COM. The conventions adopted are restricted to object interactions within the same address space and exclude detection and dynamic loading of components at runtime. The latter restriction implies that the COM library and the COM Registry are not needed. The conventions and design patterns adopted from COM are:
In addition to these conventions, this Recommended Practice also adopts the scheme for definition of result codes from COM. It is stressed that components developed according to this Recommended Practice do not conform to COM. Important differences to COM are listed in A.1.56.1.1.1.1.1.11. However, it is possible to develop and use SLE API components in a COM environment. It is also possible to write very simple COM conforming wrappers for the components conforming to this Recommended Practice. The Simple Component Model defined for the SLE API does not claim to cover all features that can be expected from a full scope component model. In particular it does not support:
For customization, this Recommended Practice uses the traditional concept of a configuration database, which is read by a component when a special method Configure() is called.
Integration of independently developed components by a third party and substitutability is required only for the four API components identified in this Recommended Practice, namely:
Therefore the term ‘component’ is only used for these modules. These components are of considerable size and complexity and support a rather large number of interfaces. It is assumed that each component makes use of several classes and creates a number of objects during operations. Some of these objects will implement functionality, which is not directly visible outside of the component, but others must be accessed by the application or by other components. In the following, objects that are visible outside of a component are referred to as ‘component objects’. The design patterns and conventions for component objects ensure that the component implementing them can be easily integrated with other API components into an SLE Application program. However, there is no requirement that a component object itself be self-contained or be individually substitutable. It must be stressed that the concept of a component object is constrained to the external view of a component. There is no requirement that a component object is actually implemented by a single C++ object. A single component object may be implemented by co-operation of several C++ objects and a single C++ object could provide the implementation of more than one component object. This Recommended Practice makes no assumptions on the internal design or implementation of a component. All conventions defined in this annex only apply to component objects. Therefore component objects are also referred to simply as ‘objects’ in this annex.
|