Making EuropeanIndustry MoreCompetitive

F or Europe to remain competitive, thecapabilities of its industry in ground

operations software must continue togrow. Building on the expertise of ESOC, theultimate goal is a suite of ‘plug and play’software that users could call on by selectingthe various components from Europeansuppliers.

IntroductionESA’s mission is to shape the developmentof Europe’s space capability and to ensurethat investment in the space sectorcontinues to deliver benefits to Europe’scitizens. In practical terms, this means thatESA has to ensure that Europe’s spaceindustry develops and maintains thesecapabilities. They must cover a wide range,spanning the space segment, launchers andground segments. Another challenge is tosupply space systems at competitiveprices. Ambitious space programmes withlimited budgets make this essentialeverywhere. Another significant aspect isthe globalisation of the space business andthe growth and improvements of technicalstandards that enable global inter-operation. To be a player in the world spacemarket, European industry must offercompetitive solutions. This article describesan initiative to develop and strengthenindustry capabilities in operations softwarefor the ground segment. This involvespromoting reusable software productsoriginally developed for ESA purposes.The effort began around 5 years ago withthe SCOS-2000 mission control kernel.This initial effort was very successful andis now being extended to the much widerpalette of products forming the ESOCGround Operations Software (EGOS). Thearticle also draws together the variousthreads that make such an endeavourpossible; these include standardisation and

Michael Jones & Nestor Peccia Ground Segment Engineering Department, ESADirectorate of Operations and Infrastructure,ESOC, Darmstadt, Germany

esa bulletin 126 - may 2006 55

Software

The Example ofESOC’s

OperationalSoftware

ground segment technology harmonisation.The ultimate aim is to encourage theemergence of a European suite of groundoperations software, from which usersmeet their needs in a ‘plug and play’manner by selecting components fromEuropean suppliers.

Ground Segment Operations SoftwareFor many years, ESOC has beendeveloping high-quality software for itscore business of spacecraft operations. This includes software for:

– mission control: command and controlof the spacecraft;

– simulators: providing support for testingthe system and training the operationspersonnel;

– flight dynamics: controlling the attitudeand orbit of the spacecraft;

– mission analysis: designing the missionfor manoeuvres and flybys to achievemission aims.

Much of this software is used andrigorously tested for the demanding tasksof preparing and supporting spacecraftoperations. Because of ESOC’s need toapply it to many missions, much of it wasdesigned for reuse, as one of the mosteffective ways to increase productivity.

Risk reduction is another importantadvantage, since reused software hasalready been validated operationally.

The idea then arises: why not encourageother spacecraft operators to use thissoftware and take benefit of theinvestments already made? Linked to thisis the consideration that suppliers of suchsoftware are also looking for business withother spacecraft operators, so this wouldopen up new markets. Indeed, this couldapply not only to ESOC’s suppliers, butalso to any European company able toexploit the software. It follows that suchreuse could help to make Europeanindustry more competitive.

In fact, ESA has been doing this formany years via the licensing of a widerange of software developed for ESApurposes, although it was left to theinitiative of the licensees to exploit thesoftware, commercially or otherwise.Furthermore, in the last 5 years or so,ESOC has been promoting certainsoftware as supported ‘products’. The seedfor this was ESOC’s SCOS-2000 missioncontrol kernel, but the idea has now beenbroadened. As described later, it willeventually include the full range of groundsystems software.

Reusable SoftwareReusable software has to be designed anddeveloped for reuse from the outset. Thereis a rule of thumb that if more than about20% of a software module has to berewritten when reusing it, then it is moreeffective to design and rewrite the wholemodule from scratch. The challenge ofdeveloping reusable software is to staywell below this threshold. This can beachieved via various techniques, such as;

– allowing configurability via the settingof parameters or a via database;

– allowing extension of functionalityusing software engineering techniques

Operations & Infrastructure

esa bulletin 126 - may 2006 www.esa.int56

Working in the ESOC backup Mission Control Room

Mimic Display from the MetOp Mission Control System, based onSCOS-2000. ESOC will support the Launch and Early Orbit Phaseof Eumetsat’s MetOp weather satellites

such as inheritance in object-orientedmethods. This allows the reusedsoftware to remain unchanged, theadditional functions being provided viathe use of ‘derived classes’.

Standardisation Another enabling factor for reusableground systems software is standardisa-tion. Space agencies and industry haveinvested in engineering standardisation asa means of decreasing project risks andreducing development and operationscosts. Risks are reduced because standard-isation offers proven and consolidatedprocesses, methods and interfaces. Cost isreduced because standardisation permitsreuse of processes, solutions andcomponents.

For space engineering, there are twomain bodies concerned with standardisa-tion: the Consultative Committee forSpace Data Systems (CCSDS), and theEuropean Cooperation for SpaceStandardisation (ECSS)

The CCSDS is an internationalstandardisation body primarily addressingcommunications and data-handlingtechniques for interoperability betweendifferent space agencies, and standardisa-tion of space-related informationtechnologies. Today, membership ofCCSDS includes ten space agencies andseveral other participating organisations in

the form of observers, associates andliaisons.

The ECSS was established in 1993 todevelop a coherent, single set of standardsfor use in all design and development ofspace systems in Europe. It involves ESAand the national space agencies, and,importantly, it includes European industryunder the umbrella of Eurospace.Eurospace is a non-profit organisation thatfosters the development of space activitiesin Europe and promotes a betterunderstanding of space industry-relatedissues. This means that, in ECSS, both theinstitutions and industry are stakeholdersin the standards.

CCSDS and ECSS have between themproduced a large body of engineeringstandards that are now in regular use,particularly in ESA. A number of thesestandards have allowed the development ofstandard components (or infrastructure)for ground systems software. Examplesare:

– from the CCSDS, the Space LinkExtension (SLE) services, whichprovide standard interfaces to groundstations, permitting one agency to usethe ground station of another;

– from the ECSS, standards of particularrelevance are ECSS-E-70A, which is thetop-level standard defining the processlifecycle of developing and using

operations systems, and the Telemetry &Telecommand Packet UtilisationStandard, ECSS-E-70-41, which identifiesa set of services for using telecommandpackets and telemetry source packets inthe remote monitoring and control ofpayloads space systems.

These examples merely scratch thesurface but the point is that softwaredeveloped to support such standards isnaturally reusable.

Early Days: MSSS and SCOSAt ESOC, it has been the practice for some30 years to use a generic mission controlsystem as the basis for the control systemof each mission. This was first done in themid-1970s with the Multi-SatelliteSupport System (MSSS). The basicconcepts of this system were that:

– it could be configured to support severalmissions at the same time;

– it was table-driven. The data structuresof the commands and telemetry data ofthe each spacecraft were defined intables, so customisation to a newspacecraft could be done largely byupdating tables.

These were novel concepts for the time.MSSS was highly successful and remainedin use for well over 20 years. It was alsoused as the basis for some systemsdeveloped commercially for other space-craft, in particular the Inmarsat MissionControl System (MCS).

The next MCS generation was theSpacecraft Operations Control System(SCOS). The first generation SCOS-I wasdeveloped in the mid-1980s and had acentralised architecture based on VAXminicomputers. Like MSSS, it wasimplemented mainly in FORTRAN.SCOS-I systems continue to supportseveral major ESA missions: Envisat,ERS-2 and Cluster.

Growing Maturity: SCOS-2000The successor to SCOS-I was SCOS-II,later renamed SCOS-2000. Early versions

esa bulletin 126 - may 2006www.esa.int 57

Software

A session in ESOC’s Simulation Studio

were used for the control system of theHuygens Titan probe, the control systemfor the launch and early orbit phase ofMeteosat-7, and a low-cost control systemfor the Teamsat young engineers’ satellite.The launches of all of these weresuccessfully supported in 1997. In the caseof Huygens, the system remained in useuntil its successful landing on Titan inJanuary 2005.

Despite the similar name, SCOS-2000was completely new. It used client servertechnology in a distributed system of SunSolaris workstations. Designed usingobject-oriented methods, it was written inC++, and developed with the followingstrategic aims:

– ease of configuration and/or customisa-tion, therefore lowering associated costs;

– functional richness, reducing the needfor mission-dedicated functions andlowering mission-specific costs;

– scalability, allowing the system to beadapted to missions of any size or forany phase of a mission;

– vendor independence, which reduces oravoids the need for periodic migrationexercises as hardware platforms orCommercial Off The Shelf (COTS)software becomes obsolete.

All four aims have been achieved.Vendor independence was fully achievedin 2002 with the introduction of a SCOS-2000 version that could run on either SunSolaris or Linux platforms.

Promoting SCOS-2000As a consequence of using SCOS-2000,costs of ESOC control systems have comedown by a factor of 2–3, and more in somecases. This reinforced the thoughts aboutthe possible wider use in the space sector.SCOS-2000 had some clear advantages forthis.

Firstly, it was classed by ESA as‘operational software’, which meant thatESA owned the Intellectual PropertyRights. According to the ESA Convention,

this gives the ESA Member States andbodies under their jurisdiction the right tohave a licence to it free of charge.

Secondly, continuity of support isguaranteed since SCOS-2000 is used byESA on all missions supported by ESOC.In particular, the ESA Investment Planfunds basic maintenance and keeping ofthe product in step with evolution of theunderlying technology and platforms. ESAis using SCOS-2000 on major programmessuch as Rosetta (launched in 2004, due toarrive at its target comet in 2014), MarsExpress, Venus Express and the Galileoconstellation of navigation satellites. Thusthe product necessarily has a long timehorizon. The promotion of SCOS-2000began in 2000 by:

– ensuring that experience with SCOS-2000 and its technology was well spreadamong ESOC’s frame contractors. Thecontractors carry out all thedevelopment of mission control systeminfrastructure and of mission controlsystems at ESOC;

– encouraging these contractors to useSCOS-2000 in their bids to othercustomers within and beyond ESA;

– holding regular workshops to shareexperience on the use of SCOS-2000between its users;

– providing training courses.

As a result of these and othermeasures, SCOS-2000 is now in use bymany operators. The table shows thatthe overwhelming choice for theoperating system is Linux, whichresoundingly confirms the correctness ofthe decision to make Linux one of theSCOS-2000 operating systems. The listincludes several examples of using the

system for spacecraft checkout. There isalso an example of reuse in a differentbut related field to that for which it wasoriginally developed. This came as aninitiative from the ESA Directorate ofScience, which chose SCOS-2000 as aplatform for the Central Control Systemsupporting assembly, integration andtest activities on the Herschel/Planckplatform and its payloads.

In the Eutelsat case, ‘NEO’ controls afleet of satellites from European, US andRussian manufacturers. NEO replaced a‘park’ of different control systems with asingle solution based on the SCOS-2000platform. The NEO project also resulted ina joint venture called ‘hifly©’ between twoEuropean companies, SciSys (UK) andGMV (E). According to the companies,hifly© product is an MCS solution forcommercial satellite operations that is“powered by SCOS-2000”.

In the case of DLR’s German SpaceOperations Centre at Oberpfaffenhofen,near Munich, SCOS-2000 was selected asa cost-effective solution to replace anageing Compaq/VAX architecture.

Expanding the ScopeIt is clear that SCOS-2000 has become a‘best-selling’ software product, with some70 licenses granted over the last 6 years. Infact, it is now a world-leading MCSproduct.

By 2002, it became obvious that therewere other candidate products, such as:

– ESOC’s generic simulator infrastructureSIMSAT (Software Infrastructure forModelling Satellites), which also has apedigree stretching back over 20 years;

– the SLE Application ProgrammerInterface package, which provides a

standard means of communic-ating with the ground stationbackend over the TCP/IPcommunications protocol, andalso provides cross-supportcapability with other agencies.

It was also becoming clear thatsynergies could be achievedbetween the various products.For example, SIMSAT was

Operations & Infrastructure

esa bulletin 126 - may 2006 www.esa.int58

Projects using SCOS-2000 outside of ESOC

originally developed to run onMS Windows, which apart from limitingsynergy with the UNIX/ Linux systems ofSCOS-2000, also implied the support of afurther information and communicationstechnology infrastructure at ESOC.

Organisational ConsiderationsDifferences in organisational responsibilityled to the divergences mentioned above,including the use of different platforms,different COTS software, and differentsoftware solutions for common problemssuch as logging and error handling. Thevarious responsible units had independentlydeveloped parts of the infrastructurewithout considering potential common-alities in technology, design andimplementation.

In 2002, the management of ESOC’sGround Systems Engineering Departmentdecided to add two new divisions:

– the Data Systems Infrastructure Division,responsible for the implementation andmaintenance of the generic mission datasystem infrastructure, including missioncontrol systems, simulators and groundstation backend software;

– the Mission Data Systems Division,responsible for implementation andmaintenance of mission control systemsand simulators for missions. Thisdivision is also the counterpart to the‘customer’, which for an ESA mission isrepresented by the flight control teamand its management.

This reorganisation had two maineffects. First, it put mission control,simulator and ground station infrastructuresoftware under the control of a single unit.This unit, the Data Systems InfrastructureDivision, has the mandate to ensureconsistency and synergy betweeninfrastructure products. Secondly, it allowsthat unit to focus on reuse, be it ofinfrastructure or of software developedspecifically for particular families ofmissions.

ESA/ESOC Ground Operations SoftwareIn the 3 years since the new organisation

was set up, the process of expanding thescope and coherence of the infrastructurehas proceeded rapidly. Notable achieve-ments have been:

– porting of the simulator infrastructure toLinux/PC platforms;

– the development of a new generation oftelemetry and telecommand encoders,integrated in one package, TMTCS,and supporting the SLE services;

– extension of SCOS-2000 to supportmultiple spacecraft. This is essential forconstellation missions such as Galileoand for future formation-flying missions.

esa bulletin 126 - may 2006www.esa.int 59

Software

The envisaged future architecture of ESOC ground segments,including operations automation. EMS: ESTRACK ManagementSystem. FDS: Flight Dynamics System. G/S: ground station.MATIS: Mission Automation System. MCS: Mission Control System.MPS: Mission Planning System. NIS: Network Interface System.OPS: Operations Preparations System. STC: Station Computer.TC: telecommand. TM: telemetry

EGOS components, with layering into low-, middle- and high-levelcomponents. EDSS: EGOS Data Distribution System.GUI: Graphical User Interface. MAS: Mission Automation System.NIS: Network Interface System. OBSM: On-Board SoftwareManagement (System). SMF: Services Management Framework.

This also enables server consolidation– reducing the number of servers;– reengineering of EGOS components,

involving the identification and layeringof common functions and services, withthe aim of reducing the amount of‘middleware’ and low-level software,and avoiding duplication.

Work has started on a MissionAutomation System (MATIS) and theESTRACK Management System (EMS;ESTRACK is the ESA ground stationnetwork).

Evolution not RevolutionThe general philosophy followed forEGOS is ‘evolution not revolution’. Thisemphasises reuse or, more broadly,reengineering of existing software. Newproducts and product lines are developedto respond to new services or needs.However, even in this case, availableproducts are taken as the basis for newproduct lines wherever feasible. Bearingin mind that reusable software is in effecta repository of knowledge, we try to avoidredevelopment from scratch, since thisrisks losing this embedded knowledge and

may even create new problems if theredevelopment is based on wrongassumptions or requirements.

Technology Harmonisation The process of devising an improvedstrategy for the evolution of European spacetechnology began in 2000 in response toa resolution at the ESA Ministerial Councilof May 1999 entitled Shaping the Futureof Europe in Space. This resolutionincluded the statement “… the new anddemanding challenges of the 21st Centurycall for a concerted European effort, sothat Europe achieves its fullest potentialfor international cooperation and worldcompetition”. This resulted in aTechnology Harmonisation initiative.Broadly speaking, its approach was to:

– identify the technology needs forEuropean space programmes. Thesewere set out in the European SpaceTechnology Requirements Document alsoreferred to as Dossier 0. This coverssome 22 technology areas, one ofwhich is ground systems software;

– make a consolidated plan of all relevanttechnology-development activities in

Europe, including an overview of allplanned institutional space technologyprogrammes, with related strategicplans (‘roadmaps’). This is theEuropean Space Technology MasterPlan.

The idea, therefore, is to ensure that theR&D contributions of the partners arecomplementary, avoiding wasteful overlapsor the spreading of resources too thinly.In the ground systems software area, theproblem of lack of strategic control hadbeen evident for many years: manysuppliers were producing incompatiblesolutions, even though they addressed thesame problem.

In the particular case of ground systemssoftware, the harmonisation approach wasdone in three phases:

1.define, in agreement with the users, acommon system standard architecturewith common requirements for theidentified blocks (‘modules’) in thearchitecture;

2.define standard interfaces between themodels;

3. produce the needed solutions respondingto the common requirements and usingthe standard interfaces, reusing orreengineering as far as possibleexisting products. This, of course, is inline with the ‘evolution not revolution’philosophy.

The outputs of Phases 1 and 2 areintended to be inputs to the ECSSstandardisation process.

The Steering Board of EuropeanTechnology Harmonisation on GroundSystems Software was set up to overseethis plan. Contracts were let under ESA’sTechnology Research Programme to carryout the work. The Steering Board hasrepresentatives from ESA and nationalagencies (ASI, CNES, DLR, BNSC,CDTI, ASA) and the European softwareindustry (Critical, Dataspazio, GMV,

Operations & Infrastructure

esa bulletin 126 - may 2006 www.esa.int60

How a system can be built up in alternative ways as ‘plug andplay’. EGSE: electrical ground support equipment. HCI: Human-Computer Interface. OBSW: On-Board SoftWare. OMG: ObjectManagement Group. SLE: Space Link Extension

LogicaCMG, Terma, SciSys, Siemens,VCS, Vega).

Phase 1 has been completed, with areviewed set of documents comprising theHigh-Level Requirements and thearchitecture. Phase 2 is under way todefine (as proposed standards) by the endof 2006 the following four majorinterfaces:

– monitoring and control to flight dynamics;– flight dynamics to mission planning;– mission planning to monitoring and

control;– simulator to electrical ground support

equipment (EGSE).

The vision is that technology harmonisa-tion of ground systems software will enableEGOS to become a European GroundOperations System.

ConclusionsThe benefits that reusable software canbring to an organisation like ESA havebeen shown. A consequence is that otherspacecraft operators can use this softwareand European industry can use it to gain acompetitive edge, as demonstrated by thenumber of successful projects based onESA/ESOC products, in particular SCOS-2000. Success has depended on a strongstrategic vision, exploiting the advantages

that standardisation brings, and having anappropriate organisation to develop theproducts and apply them. The success hasalso depended on strong cooperation withindustry, in particular from ESOC’s in-house suppliers, who have been active inselling solutions based upon ESOCoperations software products. TheEuropean Technology Harmonisation onGround Systems Software is expected toexpand this initiative further, both byresulting in further standardisation ofservices, architecture and interfaces and bybringing in the institutional and industryplayers at the European level. e

esa bulletin 126 - may 2006www.esa.int 61

Software