A step towards interoperability : Modelling of Spacecraft Monitoring

1
A step towards interoperability
Modelling of Spacecraft Monitoring Control
Automation Service
AuthorsErwann Poupart CNESPierre-Alban Cros CS
2
Content
Modelling of Spacecraft Monitoring Control
Automation Service

• Context and Objectives
• Strategy
• Results
• Conclusion

3
CCSDS SMC High Level Goals
Context and Objectives

• Standardisation of interfaces for SMC
• Reduce cost of Flight Components and Ground
  Segment Infrastructure
• Enable plug and play architecture with
  components from different Agencies, systems and
  suppliers
• Enable Mission Economies through
• Interoperability with partner systems and
  infrastructure
• Re-use of systems and operational concepts
  increased reliability
• Facilitation of Development of Generic Software
  Infrastructure (On-board and Ground-based)

4
CCSDS SMC Service Layering
Context and Objectives
5
Context and Objectives
CCSDS SMC Red Books
High level services red books (CNES,CSA,BNSC)
High priority red books (low level
services) (ESA, NASA)
6
CNES RD study objectives
Context and Objectives

• Defining formally Automation to obtain
  interoperability and to guarantee that the
  procedure will execute exactly as specified.
• Identifying SMC services involved and validating
  their completeness.
• Be able to connect Automation with any other
  service.
• Be ready to take into account any Spacecraft
  Operations Language or meta-model.
• Preparing a prototyping exercise to validate
  those results.
• Building the consolidated release of SMC
  Automation service red book.

7
Strategy
Automation process is usually specified at design
time using a spacecraft operations language. The
corresponding procedure is usually executed on an
engine doing the Automation Process, following a
path in a graph corresponding to its
specification.
To be able to say what and how Automation Service
could be provided by automation process (the
engine), it was necessary to study it in the
space domain and identify its goals. This was
done on European languages and tools (PLUTO,
ELISA, MOIS, TMTCS).
To identify which SMC services were involved and
their completeness, it was necessary to identify
them in existing procedures coming from different
contexts. This was done on procedures operating
DEMETER and PARASOL micro-satellites, ARIANE,
ATV, and Telecom 2 satellite. Operational people
involved in EGSE or different control centres
were interviewed.
8
Strategy
Interoperability key points

• One important interoperability key point of this
  study was to make a clear separation between the
  concepts related to
• The Automation process,
• The services used by this Automation process
  (defined in current SMC red books),
• The services using this Automation process
  (Automation, Scheduling, etc.),
• The Automation service itself.

Like this, Automation process engine only takes
care of the What and When while the SMC
services take care of the How and By whom
9
Strategy
Interoperability key points
Other key points to achieve interoperability are
the completeness and the formal semantic about
concepts to define how they should be
interpreted, because ambiguous definitions leads
to misunderstanding and makes Automation
components unable to understand each other.
Automation interoperability may be achieved if
the concepts concerning all the parts (SMC
services and Automation process) are defined
formally.
Many formalisms, languages, meta-models describes
concepts, their relation, their constraints, but
concerning the description of the semantic, i.e.
how to interpret those concepts and execute them,
there is a lack in their description leading to
misunderstanding.
10
Strategy
Concerning Automation process, in the space
domain, there are many spacecraft operations
languages, not only in Europe, which contain
concepts related to it. And, outside the space
domain, the situation is similar with many
automation languages, also called workflow
languages, and meta-models unable to understand
each other. Many studies had already been made
at QUT (Queensland University of Technology,
Australia) and EUT (Eindhoven University of
Technology, Netherlands) on more than 30 existing
workflow systems and languages among with
standards like XPDL, BPEL4WS, XLANG, UML2 AD,
etc., focusing on differences and
interoperability aspects. To achieve those
studies, they used workflow patterns related to
control-flow, data, and resource
perspectives. The conclusion was that all
workflow patterns were not supported and that
there was a lack on semantic description. Petri
net formalism was used to solve this problem.
11
Results
We have done a similar study using those patterns
on European Spacecraft Operations languages and
tools like PLUTO, ELISA, TMTCS and MOIS. The
results are
Control flow patterns identified in Spacecraft
Operation languages
12
Results
Data flow patterns identified in Spacecraft
Operations languages
Data based routing
External data interaction
Internal data interaction
Data visibility
13
Results
Concerning the services executed by Spacecraft
Operations languages, we studied existing
procedures operating DEMETER and PARASOL
micro-satellites, ARIANE, ATV, and Telecom 2
satellite. Then, we mapped those services on SMC
services, the results are
SMC low level services used by SMC Automation

SMC Core service

• Core.Monitoring.Status (register, deregister and
  update) to perform checks on telemetry
  parameters.
• Core.Monitoring.behaviour to enable/disable
  parameter checks.
• Core.Monitoring.Action and Core.Monitoring.Verifi
  cation to send commands to the spacecraft.
• Core.Monitoring.Alerts to get alerts from the
  spacecraft or from the ground monitoring
  activity.

14
Results
SMC low level services used by SMC Automation

SMC Common service

• Common.Active.Observe, Common.Active.Interact
  and Common.History to interact with the operator,
  log information, or send mission specific events.

15
Results
SMC high level services used by SMC Automation

• Automation.Control itself to stop/start or
  suspend/resume the current activity.
• Automation service onboard, to send delayed
  commands or onboard procedures to the
  spacecraft.
• Time Service to get timeout events, set timeout
  in a relative or absolute way.
• Flight dynamics service to get orbit, attitude,
  etc.
• Remote Software Management service to load
  software image onboard, etc.

16
Results
Services provided by SMC Automation
17
Conclusion

• It is possible to define formally the Automation
  process.
• This study validates that Automation can take
  into account any Spacecraft Operation Language or
  meta-model.
• Automation service can be integrated into SMC
  architecture.
• It is possible to connect Automation with any
  other service.
• A prototyping exercise is possible and will
  allow to validate the results of the study. This
  will be done at CNES by the end of the year using
  existing DEMETER procedures.
• Some further studies could be made concerning
  spacecraft operations languages translation,
  edition and execution using one dedicated
  language perspective, etc.

18
Any Questions ?