1.1.3 Defining the operating environment

Author: ACTIONS demonstrator project

In contrast to the majority of terrestrial robotic systems, a spacecraft’s local environment is relatively simple and well-understood [1]. However, a space system is more than just the spacecraft. It is typically composed of:

• The space segment – the satellites, subsystems and payloads
• The ground segment – ground station equipment and operations infrastructure
• The service or user segment – for relevant missions, the means by which end users benefit from mission applications (e.g. provision of satellite data, ground-based telecommunication networks, etc.)

It is the service segment which typically drives the goals and requirements of the mission. The operating environment of a space system must therefore consider all three segments to be truly representative of the satellite’s safety, particularly for autonomous behaviours which impact ground-based stakeholders. The operating environment of a generic space system then includes the elements described in Table 1. Note that the satellite itself can be considered part of the environment, as some autonomy software may be limited to a payload (e.g. for data management and delivery) which is hosted on the satellite platform.

Table 1 – List of operational environment elements for each segment in a satellite space system.

The operating environment is therefore expansive. For missions with many end users, such as those contributing to the EU’s Copernicus platform, there are a huge number of use cases and applications of satellite data. If even some of the ground-based data activities were moved on-board the satellite, the number of different requirements on these activities and the conflicts between them would be considerable. Guidance on defining operational scenarios generally for space systems is provided by ECSS and heavily employs the concept of mission use cases [2].

Application to autonomous space systems

When considering autonomous satellite missions, specific operating scenarios must therefore be considered to scope the expected behaviour of the autonomous elements and precisely capture the parameters of the space, ground and service segments. Consider a satellite mission with the goal of autonomously detecting and reporting the presence and location of wildfires, as was explored in the ACTIONS demonstrator project. Operating scenarios could limit this behaviour to conditions such as:

• Time of day – daytime sensing conditions are significantly different from night-time.
• Time of year – the appearance of sensed features can change significantly over the year, and with different weather conditions.
• Specific regions of interest (e.g. countries, states, biomes) – this impacts both region-sensitive features and mission properties such as data volume, ground station pass timings, etc. There is then a further impact on performance metrics such as data throughput and delivery latencies.
• Specific use cases for mission data – manifested primarily in the service segment. For ACTIONS, an emergency service end user was considered with one set of requirements and a commercial end user had a different set.

Operating scenarios could also consider both nominal conditions and off-nominal conditions such as:

• Anomalies in autonomous system – such as sensor degradation and single events in computing hardware.
• Edge and corner cases – for inputs to the sensing part of the system, e.g. input data with low representation in training and internal test data.

Scoping the operating scenarios of the autonomous space systems in these ways allows the safety, performance and other requirements of the system to be more precisely defined. It also provides clear test scenarios for real-time or near real-time simulation testing and ultimately validation of the system requirements.

Operational scenarios of ACTIONS project

The ACTIONS demonstrator project employed a wildfire detection and reporting mission as a case study, with emergency alerts and data products delivered to service segments to the benefit of emergency services and commercial customers, respectively. A single operational scenario was defined with the properties shown in Table 2. For real-time simulation testing, the operational scenario was further reduced to consider a specific time window. The scope of the scenario at the requirements stage informed the selection of training and test data for the autonomy software and machine learning component, while the scope of the simulation informed the selection of simulation test data.

Table 2 – Scope of operational scenario elements for ACTIONS demonstrator mission.

Scoping the operational scenario of the wildfire mission then allowed hazards impacting the autonomous behaviours of the mission to be identified, which, for the emergency use case, were:

• That the wildfire is not responded to in sufficient time to contain or eliminate it
• That emergency services were directed to a location which has no wildfire, wasting their time and diverting them from real emergencies

The same logic could then be applied to the commercial use case for non-safety critical hazards. From these hazards, failure modes can then be identified. Standards for hazard and failure mode analysis in space systems are provided by ECSS [3, 4].

Summary of approach

1. Design and plan mission using high-level planning tools, including full operating environment.
2. Scope operating scenario(s) for mission such that requirements can be precisely defined and are verifiable, considering such elements as time of day and year, region of interest and use cases.
3. Verify requirements through testing (including simulation), further narrowing the scope of the scenarios as needed.

References

[1]         ECSS, ‘Space Engineering: Space Environment’, ECSS, Noordwijk, Standard ECSS-E-ST-10-04C Rev.1, Jun. 2020.

[2]         ECSS, ‘Space engineering: Software Engineering Handbook’, ECSS, Noordwijk, Handbook ECSS-E-HB-40A, Dec. 2013.

[3]         ECSS, ‘Space Product Assurance: Failure Modes, Effects (and Criticality) Analysis (FMEA/FMECA)’, ECSS, Noordwijk, Standard ECSS-Q-ST-30-02C, Mar. 2009.

[4]         ECSS, ‘Space Product Assurance: Hazard Analysis’, ECSS, Noordwijk, Standard ECSS-Q-ST-40-02C, Nov. 2008.

[1] Although the area of interest is typically ground-based, it is sensed from the space segment and therefore considered part of this segment