Product Overview

GenOne

GenerationOne, is the core technology behind all Bright Ascension products, including both the development kits like HELIX® Flightkit the FSDK and off-the-shelf solutions such as the HELIX® Ops and the MCS. Understanding GenOne is crucial as it forms the backbone of our approach to software development, offering a unique combination of model-driven design, service orientation, and component-based architecture.

Figure 1. The 3 pillars of GenOne

What is GenOne?

GenerationOne is the central technology in all Bright Ascension software. We provide it to customers in our development kits, it’s built into our off-the-shelf products, and we use it ourselves when we develop mission-specific software for customers. It’s in the DNA of everything we do.

GenOne is Model-driven, Service-oriented, and Component-based:

Our Model captures information about the facilities and structure of software systems.
Components are the primary units of software in GenOne.
Services define the ways that Components can provide facilities, and how those facilities can be accessed.

Those 3 simple elements are the pillars of GenOne. Though simple, they combine to underpin our products in really powerful ways.

Models

Models are the most fundamental aspect of GenOne - they’re the foundation that everything else build on. Our Models are machine-readable, which means they can be leveraged across the full mission life-cycle. Our development kits are built around them, automating large parts of the software development workflow.

Components

Components are one of the key aspects that allow GenOne to realise the flexibility offered by our Model-driven approach. Being Component-based means software is constructed from well-defined self-contained elements, which are flexible and intrinsically reusable.

Services

Services are the other key aspect that allows GenOne to realise the flexibility offered by our Model-driven approach. A Service-oriented approach means that specific Components don’t have to be hard-linked to other Components, allowing them to be combined in many different ways depending on the needs of individual missions. Services describe the facilities and behaviour that Components either provide or require.

A Component that provides a Service is promising to behave in a certain way, and so a Component that uses that Service knows exactly what to expect, despite not knowing which specific Component realises that behaviour or where it is located. This provides a flexible way of integrating software components.

HELIX® Suite

The HELIX® suite of products offers a highly-integrated end-to-end space software solution – from flight software to ground operations and data-insights applications. It tightly connects the currently disjointed and fragmented space software systems for significantly improved efficiency, simplicity and noticeably lower costs.

Development Kits

Our development kits use GenOne to deliver in key areas:

Reuse: A development kit comes with pre-defined Services and a library of pre-tested Component Implementations, to get mission development up and running quickly.

Ease of use: Our Model-driven tooling makes it easy to implement new Components, and to use Services to combine them effectively. You can think of this like building with building blocks.

Rapid integration: Our tooling connects Component Implementations together automatically based on information in the Model, and deploys them into complete software systems.

HELIX® Flightkit (Formerly the FSDK)

HELIX® Flightkit is a purpose-built solution aimed at simplifying and accelerating the development and validation of onboard software. The Flightkit is built around components, each with a standard interface, that can be easily added or removed. These components encapsulate the key functions of the onboard software. Flightkit comes with a library of components that cover most typical functions required by onboard software, along with a set of components for interfacing with common hardware.

The software, from an operator’s perspective, is a loosely coupled set of components. Each component is a reusable, standalone software module that encapsulates a related set of functions and data, and has a well-defined interface. Some components represent specific hardware subsystems, such as the Electrical Power System (EPS), while others are purely software-based, providing capabilities like telemetry aggregation or monitoring.

Common Components
Subsystem Components	Data Handling & Monitoring Components	Communications Components	Automation Components	Mission-Specific & Custom Components
• EPS, battery, ADCS, payload • Support for many off-the-shelf hardware subsystems • AAC Clyde Space, GOMspace, ISIS, Pumpkin, Skylabs, Xiphos and more	• Sampling, data pool, aggregation, logging, monitoring, statistics • Support for most common onboard monitoring functions	• Packet handling, telemetry reporting • Absolute and relative time scheduling, orbit-based scheduling • Event-based automation • Onboard scripting • Includes support for CCSDS TM/TC, ECSS PUS, CFDP, CSP	• Absolute and relative time scheduling, orbit-based scheduling • Event-based automation • Onboard scripting	• Mode management, deployment sequencing, orbit counting

Interaction with components is performed through actions and parameters. Actions are functions that a component can be commanded to perform, and parameters represent data associated with a component. Some parameters are read-only, often representing onboard measurements, while others are read-write, used to modify a component’s configuration. Parameters can be scalar or vector, with vector parameters having a number of rows of equal length. Some parameters have a fixed number of rows, while others have a variable number of rows. Unusual conditions when using an action or parameter result in exceptions, and components may issue events to indicate unusual conditions occurring asynchronously.

Off-the-shelf Products

Figure 2. The Bright Ascension Product Suite

For our off-the-shelf products interoperability is key, and GenOne is how we achieve this:

Common language: All of our software uses GenOne Services to define its capabilities, so everything talks the same language.

Shared understanding: All software systems share their capabilities in the same Model, so they have a common understanding of what each other can do and how to interact. For example HELIX® Ops uses the Model to understand the capabilities of the flight software, so it can present them to the operator as well as interacting with the spacecraft directly via automation.

HELIX® Ops (Formerly the MCS)

HELIX® Ops is a specialised interface designed to interact with onboard software (OBSW) created with the GenerationOne flight software. Ops communicates with the OBSW through various components built by the GenerationOne flight software, forming the core of the spacecraft’s operations.

In essence, Ops serves as an interface that simplifies the complex task of spacecraft operation, making it accessible and manageable. A Python API is provided to allow for automation and unattended orchestration of the spacecraft. Ops encapsulates the key functions of the mission control software, providing comprehensive tools for spacecraft operation and management. Through its well-defined interfaces and modular components, Ops offers a streamlined and intuitive approach to spacecraft operation.