A practical approach to software portability

The approach is being resolved by the JSC “м. F. Reshetnev “Information satellite systems” in collaboration with the Ershov Institute of Informatics Systems and the Excelsior, Ltd. (formerly XDS), via an approach based on architectural stratification and interface standardization both for the onboard software and the development environment and the Modula-2 programming language especial features [1], such as strong typing and separate compilation [2–7].

First of all, a stratification of the OSW was performed which allowed us to define and implement an OSW Abstraction layer that provides a standard platformindependent API (types and procedures) to application software (i. e. the software of satellite subsystems that solves functional problems and amounts to up to 80 % of the entire OSW). Portability of the application software to new hardware is ensured by the software development system whereas the use of a new operating system and drivers, by reprogramming the implementation modules for the OSW Abstraction layer.

Next, a stratification of the cross-programming system (CPS) was made which allowed us to define platformindependent and programming-language-oriented user interfaces: both for programming and testing/debugging needs, and the CPS Abstraction layer that provides a standard architecture-independent API (types and procedures) that isolates architecture–dependent parts of the onboard computers: CPS components implement code generation and instruction set simulator.

A successful implementation and an efficient use of both the OSW and CPS Abstraction layers proved to be possible to a great extent due to the strong typing and separate compilation properties of Modula-2.

Moreover, the use of a highly structured language provided an additional benefit, namely, a possibility to measure static and dynamic software component characteristics and to calculate criterions of software testing completeness for quality assurance.

Onboard software stratification. A canonical three-layer structure of the OSW was determined. The third layer – the application software – becomes platform-independent because its implementation only uses interfaces exported by the lower, second layer called the Abstraction layer. The first layer is the employed operating system, i. e. a real-time kernel and a set of drivers.

The canonical structure of the OSW Abstraction layer for the given problem area was determined by the analysis of functionality of several generations of satellites.

Three components are specified in the Abstraction layer:

• –    standard interfaces for a canonical set of abstract realtime kernel calls;

• –    standard interfaces for a canonical set of abstract onboard devices;

• –    standard types for a canonical abstract data set used to control subsystems of the satellite in various regimes.

The main features of Modula-2 – the strong typing and separate compilation – gave a possibility to implement the Abstraction layer as a set of Modula-2 libraries providing a complete and platform-independent API. It proved possible to define the data types independently of addressability, endian-ness, word size, etc., of various onboard computers.

The strong typing, e.g. enumeration types, provided a required level of abstraction for data types which is both maximally close to the problem field and also platformindependent to a maximal degree.

The separate compilation feature allowed us to standardize and freeze the API using definition modules, and made it possible to reuse all the functionally equivalent application software without any changes in the source code, which greatly simplified configuration management.

A Modula-2 cross-programming system adaptable to different target onboard computers. We developed a crossprogramming system (CPS) based on Modula-2, which implements the code generation for some base computer implemented via an instruction set emulator. In this CPS, there were implemented platform-independent programminglanguage-oriented user interfaces as well as the CPS Abstraction layer that provides a standard architectureindependent interface with parts that depend on the architecture of the target onboard computer: the CPS components that implement code generation and the instruction set simulator.

Adaptation CPS for a new embedded computing system is performed by creating code generation and the instruction set simulator components only. The CPS ensures that all debugging information is provided at the level and in terms of Modula-2.

The assembly of the project into executable code is done via a standard CPS shell with the use of the necessary components of the commercial software development system. Another important fact is that application programmers can notice whether a switch to a different target computer (another command set interpreter) has occurred only through changes in the program operating characteristics as measured by the CPS, because all the user interfaces stay exactly the same.

The CPS also includes testing and debugging facilities that use platform-independent testing languages. The platform-independent dialogue and batch testing languages allow programming, executing and documenting test

Vestnik. Scientific Journal of Siberian State Aerospace University named after academician M. F. Reshetnev procedures in the platform-independent terms of the programming language. The batch testing language allows one to reuse the test procedures with another platform.

The CPS runs efficiently under MS Windows 2 000/XP on Intel Pentium chips.

Such an approach was influenced by the XDS programming environment [5], and the XDS system was used as a programming environment for the CPS development and maintenance.

So, the architectural stratification of the OSW and CPS and the standardization of the two Abstraction layers ensures an easy adapation of the CPS to a new target computing platform.

An additional benefit of using a highly structured language. Our CPS allows one to obtain a complete set of measurements for the program unit being developed (including the size of stacks, the execution time, etc.) in order to evaluate some measures of source code quality and to calculate the C1 (all branches) and C (all decisions) criterions of unit testing completeness.

This is only possible with a highly structured language, so this quality allows one to implement in the CPS a complete check of the program execution process during the testing procedure and to make the testing procedure (especially under batch testing) independent of local changes in the source code of the program being tested.

The described technology of the OSW development results not only in a high level of reuse and portability of the OSW, but also a possibility to reuse all testing procedures for regressive tests of the OSW.

This is true not only for the OSW development, but also for the CPS. Moreover, it is possible to start the OSW development not waiting for adaptation of the CPS to a new target onboard computer by using the CPS available for the base onboard computer.

The measurement tools of the CPS that are based on the properties of the programming language allow one to achieve the high level of quality of the OSW components required for the spaceflight applications.

The standard and stable user interfaces of both the CPS and the Abstraction layer greatly simplify the maintenance of OSW by facilitating experience accumulation and transfer.

The technology successfully worked under development onboard software for Exspress-AM series communication satellites and for Glonass navigation system’s satellites.