iss data management system ESA’s Data Management System for the Russian Segment of the International Space Station J. Graf, C. Reimers & A. Errington ESA Directorate of Manned Spaceflight and Microgravity, ESTEC, Noordwijk, The Netherlands Role of the Data Management System It will also provide overall guidance and The first modules of the International Space navigation for the entire station. Station (ISS) will be the Functional Cargo Block (FGB, built by Russia and financed by NASA), Overall DMS-R Configuration NASA’s Node 1 and the Russian Service The Data Management System architecture of Module. As the Service Module has to be the Russian Segment and its interfaces with the autonomous from the beginning of its orbital overall International Space Station is shown life, it carries its own Data Management System in Figure 1. Ten MIL-STD buses provide the (DMS-R). interconnectivity between the various elements and equipment. The ESA-provided Service In October 1997, two flight units of the Data Management System Module onboard units are: (DMS-R) for the Service Module of the Russian Segment of the – Two Fault Tolerant Computers (Figure 2): a International Space Station were handed over by ESA to the Russian Control Computer and a Terminal Computer. Space Agency (RKA) for use by RSC Energia, the prime contractor for – Two Control Posts (Figures 3 and 4) for the Service Module and the entire Russian Segment. The Data command and control by the crew via the Management System was developed and manufactured in Europe by DMS-R, and for commanding experiments an industrial team led by Daimler-Benz Aerospace (DASA) in Bremen, and the European Robotic Arm (ERA), which Germany, under a contract placed by ESA’s Directorate of Manned is also being developed by ESA under a Spaceflight and Microgravity in Noordwijk, The Netherlands. The cooperative arrangement. project is governed by a cooperative agreement between ESA and RKA. A more detailed block diagram of the Service Module Data Management System is shown in This is the first delivery of ESA flight hardware within the International Figure 5. The Control Computer and Terminal Space Station Programme to another International Partner. It will be Computer have built-in redundancy to provide launched with the station’s third assembly flight, in December 1998. the required failure tolerance. The Control Posts can be configured to execute different, dedicated tasks or to operate in redundancy Ultimately, the Data Management System will mode. not only control the module itself, but also perform overall control, mission and failure The application software for the onboard management of the entire Russian Segment, computers is being developed by the Russian such as: Service Module contractor, RSC Energia, using – system and subsystem control, especially an ESA-provided Ground System, which guidance, navigation and control provides the hardware and software – mission management and supervisory environment to support software design, control by ground and crew development, simulation, test and validation. – management of onboard tasks and failure It is also being used to integrate hardware and recovery software into the Service Module Flight Model. – time distribution, time tagging and synchronisation Principles and implementation of failure – data acquisition and control for onboard tolerance systems and experiments The Control Computer and the Terminal – exchange of data and commands with the Computer feature a fault-masking architecture other parts of the station and are single-failure tolerant. r bulletin 93 — february 1998 bull Fault masking is achieved by majority voting deadlock situation have been verified through following parallel execution of the application many millions of simulation runs. The programs in three identical computer units. simulations and design analysis were These units are called Fault Containment performed by an independent team at the Regions. For this voting process, the Fault University of Bremen, Germany. Containment Regions must receive identical, synchronised input values in order to be able to For the Russian Service Module, the required deliver identical output values. configuration for the Fault Tolerant Computer consists of three Fault Containment Regions, Because of potential errors in data distribution, which provide masking of one deterministic some distribution rules have to be considered. fault. These are defined by the ‘Byzantine Theory’, which specifies the required number of Fault Associated ground system Containment Regions, individual data links and The DMS-R onboard equipment is comple- data distribution rounds, depending on the mented by a set of ground hardware and number of failures to be recovered. software for the application software development and verification process, as well As a result, a Byzantine Fault Tolerant as for system integration and check-out. The Computer system consists of multiple Fault Ground System is based on the Columbus Containment Regions cross-strapped by Ground Software, developed by DASA for multiple high-speed point-to-point data links. ESA’s Columbus Orbital Facility, one of Europe’s main contributions to the International In order to survive F simultaneous faults, the Space Station. The Columbus Ground system must meet the following requirements Software is a consistent set of software (according to Lamport, Shostak and Pease, products that forms the basis for a ‘The Byzantine General’s Problem’): comprehensive set of integrated ground facilities. It is also in use at NASA for the Space – the system must consist of 3F+1 Fault Station Mission Build Facility and the System Containment Regions Verification Facility. – the Fault Containment Regions must be interconnected through 2F+1 individual The Ground Segment consists of three main paths facilities: – the inputs must be exchanged F+1 times between the Fault Containment Regions 1. The Software Design and Development – the Fault Containment Regions must be Facility synchronised. 2. The Software Integration and Test Environment For data distribution, electrically-isolated full 3. The Test Facility with the necessary Electrical duplex serial data links are used to avoid error Ground Support Equipment and onboard propagation between the Fault Containment DMS engineering models for system-level Regions. The realisation of an individual data software integration. This facility is also path must be a point-to-point connection. connected to the Functional Cargo Block Keeping in mind the data throughput, which is (FGB) ground facility, provided by NASA to reduced by the required data distribution support integrated Service Module/FGB/ rounds, these data links must have very high Node/Shuttle interface verification testing. transmission rates. ESA and Russia: the cooperative This DMS-R development is the first time that experience the Byzantine Theory on failure tolerance has A challenging aspect of DMS-R development been realised for a space application. was working within two contrasting engineering cultures. A number of important differences in One of the most critical problems in the design approach became evident early on, while some of synchronised computer systems is the were not fully appreciated at the time. elimination of deadlock situations, where one software task is waiting for an event or data The old ‘Soviet’ approach to spacecraft coming from another software task, which itself development, like other activities of key is waiting for events or data from the first. In importance to the former Soviet Union, was to order to avoid such situations, all com- assign abundant resources within the prime munication paths in the software have been contractor and its various subcontractors, all modelled by an abstraction method in order to under the overall responsibility of the General reflect all related vectors and variables. The Designer, who had almost absolute power to integrity of the design and the absence of any accomplish the required task. iss data management system The development itself was driven mainly by History of European/Russian Cooperation on DMS design ideas rather than by detailed functional and interface requirements. It required very The project goes back to 1992, when discussions were initiated between close cooperation between individual Russia and Europe on potential ESA contributions to the planned Mir-2 designers, plus repeated iterations and station. One candidate was the Data Management System. However, the intermediate breadboarding of individual design political climate evolved very rapidly and the International Space Station, elements until the desired overall performance built and operated under multi-national cooperation, replaced the separate was achieved. This approach meant that Freedom and Mir-2 programmes. The European/Russian DMS was also functional and interface requirements of the confirmed for the new Space Station scenario and fully endorsed by NASA. individual design elements could change significantly during the design process, but it DMS development was formalised in an ESA/RKA Arrangement, signed on offered performance improvements and 1 March 1996, which defined ESA’s DMS obligations and RKA’s obligations, optimisation during development. Document- in exchange, to design and deliver to ESA the Russian Docking System for ation was limited to essential high-level ESA’s Automated Transfer Vehicle (ATV). The ATV, launched by Ariane-5, will requirements, as all detailed information was support ISS resupply. open to change anyway. On 10