|
The objective of this paper is to demonstrate a suitable hierarchical networking solution to improve capabilities and performances of space systems, with significant recurrent costs saving and more efficient design & manufacturing flows. Classically, a satellite can be split in two functional sub-systems: the platform and the payload complement. The platform is in charge of providing power, attitude & orbit control and up/down-link services, whereas the payload represents the scientific and/or operational instruments/transponders and embodies the objectives of the mission. One major possibility to improve the performance of payloads, by limiting the data return to pertinent information, is to process data on board thanks to a proper implementation of the payload data system. In this way, it is possible to share non-recurring development costs by exploiting a system that can be adopted by the majority of space missions. It is believed that the Modular and Scalable Payload Data System, under development by ESA, provides a suitable solution to fulfil a large range of future mission requirements. The backbone of the system is the standardised high data rate SpaceWire network http://www.ecss.nl/. As complement, a lower speed command and control bus connecting peripherals is required. For instance, at instrument level, there is a need for a “local” low complexity bus, which gives the possibility to command and control sensors and actuators. Moreover, most of the connections at sub-system level are related to discrete signals management or simple telemetry acquisitions, which can easily and efficiently be handled by a local bus. An on-board hierarchical network can therefore be defined by interconnecting high-speed links and local buses. Additionally, it is worth stressing another important aspect of the design process: Agencies and ESA in particular are frequently confronted with a big consortium of geographically spread companies located in different countries, each one developing a part of the system. Only when all the units are delivered to the system integrator, it is possible to test the complete system. Consequently, this normally happens at the final development stage and it is then often costly to face serious compatibility problems. Pre-integration would be a possible way of anticipating problems during the integration phase. In this case, a scheme allowing the interconnection of unit models (simulators, breadboards and flight-representative hardware) must be defined. For this purpose intranets and Internet can be of significant help. As a consequence of these well-identified needs a new concept has been formulated by the Agency and will extensively be described in this paper. On-board hierarchical networks have to be seen as an integrated infrastructure able to support not only software level functions but also hardware oriented diagnostic tools. As a complement to presently developed SpaceWire networks, a lower level bus must be selected. It must be reliable, flexible, easy-to-implement and it should have a strong error control and management scheme in order to ensure an appropriate availability figure. Of course, the adoption of an industrial standard bus is advisable because of the existence of development tools, devices and experience. Therefore, the use of a standard bus provides the possibility of evaluating and potentially using commercial systems, with a significant reduction of non-recurrent costs. As a consequence, ESA has recently set-up a working group with the objective of evaluating and, if needed, customising the Controller Area Network (CAN) bus (http://groups.yahoo.com/group/CAN_Space/). On this basis, it has been decided to consider the use of the CAN bus for payload systems and steps are being issued for its on-board implementation in space. As far as the lowest hierarchical level is concerned, a JTAG-like interface appears to be adequate but this selection is still subject to investigations. In the scenario presented so far, it is necessary to have a “bridge” between the SpaceWire backbone and the local CAN bus in order to provide a fully integrated system. Moreover, some additional features are needed to give autonomy to remote terminals and to release the central processing chain from repetitive standard acquisitions and management duties. For these reasons, a new device, called Remote Terminal Interface (RTI), is under development and will fulfil the above described needs; it has been specified to be used both in intelligent and non-intelligent nodes. In particular, it will be remotely programmable by means of its embedded SpaceWire links, it will include a CAN bus controller, an embedded micro-controller allowing the customisation of local functions, ADC/DAC interfaces for analogue acquisitions/driving, standard interfaces (UARTs, JTAG for debugging) and other standard devices (timers, counters, general purpose I/Os).
|
