Opus2 User Manual

Introduction

PUS C

PUS C stands for Packet Utilization Standard version C, and is formalized in ECSS-E-ST-70-41C document. It describes a way ground may communicate with a spacecraft, including both its platform and payloads. The following chapters are most relevant to the OPUS2 toolset:

chapter 5 - describing generic Service Type abstraction, which is the basis for the standard and the OPUS2 toolset,

chapter 6 - describing system (can be though of as mostly "functional") requirements for a set of standardized Service Types,

chapter 7 - describing, among others, the used data type system,

chapter 8 - describing interface requirements (generic "packet structures") for the standardized Service Types.

Familiarity with ECSS-E-ST-70-41C document is recommended before using OPUS2 toolset, but not required, as most of the relevant information is provided here and in the toolset itself.

The basic concepts of PUS C can are summarized below. Please note that summarization is done in a "bottom-up" manner, progressively building-up the abstraction, instead of "top-down" like in the standard, to make it easier to understand, as the formality of PUS C standard can present a steep learning curve, which may be unnecessary for many users.

Spacecraft is controlled and monitored via telecommands and telemetries, which are carried in packets. Telecommands are sent to the spacecraft to invoke some actions. Telemetries are produced in response to the actions, but also autonomously, as a result of on-going monitoring or events.

Each telecommand carries a Request, which may have Request Arguments, and one or more Instructions, which may have Instruction Arguments. Each Instruction may have preconditions, which need to be checked before its execution. Instructions are responsible for invoking the required actions. The status of telecommands can be tracked by Standard Service 1 (ST[1]), which is responsible for reporting, via telemetries, whether the given request is e.g., accepted, started, progressing, completed or failed. Each telemetry carries a Report, which may have Report Data Units, and one or more Notifications, which have Notification Data Units.

In order to better formalize the system requirements, the concept of a Capability is introduced. A capability is a "functionality" of the spacecraft. As per the standard: "A capability is specified by a set of operational requirements for a function of the overall space system that can be remotely controlled by the ground monitoring and control system or by other on-board applications. This Standard mainly addresses these remote controlled related requirements and especially those applicable to the subservice providers". In particular, most Capabilities are associated with a Transaction, which contains a Request, a Report, or a Request associated with a Response (a single Request may produce multiple Responses). However, some Capabilities are not associated with a Transaction, and can present a "feature" of other Capabilities, like e.g., providing a checksum for Capabilities that operate on memories.

Capabilities are grouped within Subservices, which in turn are grouped in Services. Each Service is responsible for the given aspect of Monitoring and Control, such as e.g.,:

memory management,

housekeeping,

parameter management,

etc.

In order to differentiate between the drafting of a generic standard and a mission specific deployment, the concept of Generic Service Type and Generic Service Deployment abstractions has been introduced. As per the standard:

The generic service type abstraction level, which specifies the set of generic object types and business rules that are required for ensuring the overall consistency of the service type model. This abstraction level includes all generic object types used to produce, by specialization, the standardized and the mission specific service types.

The generic service deployment abstraction level, which specifies the set of generic object types and business rules that are required to capture the space system service model. This abstraction level includes all generic object types used to capture, by instantiation, the space system services resulting from the space system overall architecture.

The standard thus differentiates between Service Types, which are generic, and Services, which are instantiations of Service Types tailored for the given mission/application. Consequently, generic Service Types contain Subservice Types, which in turn contain Capability Types, associated with Transaction Types which bind Request Types and Report types, and so on. The tailoring process involves the selection which Service Types, Subservice Types and Capabilities are to be instantiated into Services, Subservices and Capabilities. The tailoring is guided by the rules laid out in the standard - some Capabilties are required within the given Subservices, some are implied by the presence of others, and some are purely optional. In addition to the selections, the generic data types and packet structures need to be concretized: e.g., ranges and enumerated values need to be provided. Once the tailoring is done, operation of the spacecraft involves the creation of Requests, which are instances of the Request Type, and contain Instructions, which need to be of the given Instruction Type available within the given Request Type. Similarly, the received Reports are of certain Report Types.

OPUS2 Toolset

Use of PUS C typically involves, among other things:

drafting of mission specific services,

preparation of documentation,

implementation of encoding and decoding of PUS C packets,

implementation the underlying logic.

OPUS toolset was created to support the deployment of PUS C standard in missions and aims to support the above activities. It contains the following main applications:

PopulationTool - for drafting Service Types, in accordance with the PUS Foundation Model,

DocumentGenerator - for generating the documentation based on both the abstraction and tailoring choices,

TailoringTool - for performing the mission specific tailoring, selecting the services and capabilities, as well as concretizing the used data types,

FrontendGenerator - for generating PUS C Frontend, described below.

The data describing the Service Types, as well as their tailoring, is called a PUS C Population, or simply a population (of the PUS C model). It is stored natively in an XML format and can be exchanged between the applications. The documentation can be generated in both MS Word .docx and Pandoc markup .txt formats. A template document is needed (and provided as a part of the toolset) for MS Word generation. In order to facilitate encoding and decoding of packets, the toolset generates ASN.1 and ACN specifications, which can be then transpiled into C or Ada code deployable onto an embedded target and responsible for the actual transcoding. In order to handle the PUS C logic, TASTE toolchain is used: the capability implementations are instantiated as TASTE Functions, and the architecture is generated as a TASTE Interface View. Most of the functions are implemented as SDL processes, with just a few low-level support functions implemented directly in C. It needs to be noted that while some of PUS C logic is generic (e.g., request processing flow), some requires mission and platform specific functionality (access to memories or file-systems, physical devices, etc.). To differentiate between the two, the concept of PUS C Frontend and Backend is introduced:

Frontend is responsible for handling request and report related processing logic, e.g., generation of ST[1] reports, packet transcoding, instruction execution orchestration and invoking the required mission/platform-specific functionality in the Backend,

Backend provides the mission/platform-specific functionality like e.g., memory or physical device acceess.

OPUS2 toolset is responsible only for the generation of the PUS C Frontend logic - the Backend logic is left for the users to implement, according to their requirements and constraints.

OPUS2 Toolset was created as a part of 'Model Checking for Formal Verification of Space Systems' project, ESA Contract 4000133440/20/NL/CRS.

Installation

To install the software run the following commands on your TASTE machine:

   cd tool-src/
   bash add-ons/install-opus2.sh

After installation is successful, close the terminal window and open another one. Opus2 is ready to use.

Usage

Opus2 Standard Workflow

The standard workflow is as follows:

define the Service Type abstraction within the Population Tool,

[optionally] generate generic Documentation using the Document Generator,

provide the tailoring required for Service instantiation using the Tailoring Tool,

[optionally] generate generic and mission specific Documentation using the Document Generator,

generate the PUS C Frontend for TASTE, using Frontend Generator,

provide user-defined, mission-specific functionality using TASTE,

deploy the system.

Introductory Demo

OPUS2 Introductory Demo provides a quick guide how to create an application using OPUS2.

Opus2 Applications

SpaceCreator

Opus2 SpaceCreator menu

The toolset can be launched directly from TASTE's IDE - SpaceCreator. This way all the applications share the same data model (instantiated per project) and options. The data model is instantiated from the default one provided along the OPUS2 installation. All applications are accessible from the Tools->Opus2 menu.

Opus2 Toolset menu in SpaceCreator

Opus2 Population Tool

Opus2 Population Tool allows to specify Service Types, System Object Types, Behaviour Models of Capability Types, and model checking properties, as well as define Data Types used by Behaviour Models, Request Types and Response Types.

Opus2 can be started from Space Creator or as a standalone application.

To start Opus2 Population Tool from Space Creator select Tools from menu bar and then Opus2 -> Population Tool.

To start Opus2 Population Tool as a standalone program run the following command:

   Opus2.PopulationToolGui

It is also possible to start standalone application within existing project without Space Creator. To do this run the following command from project directory:

   Opus2.PopulationToolGui opus2_model.xml opus2_options.xml

opus2_model.xml and opus2_options.xml are prepared by SpaceCreator the first time the tool is launched from within SpaceCreator for a new project. However, user can access these files manually. Within Opus2 repository, they are available under the following path:

   data/default_model

On a default TASTE system, the absolute path is expected to be as follows:

   $HOME/tool-inst/lib/Opus2/opus2/data/default_model

Opus2 Population Tool usage screens

Opus2 Population Tool Service Type view

ServiceTypeGeneralTab
Tip: General information about Service Type

ServiceTypeMessageTypesTab
Tip: All Message Types defined by ServiceType

ServiceTypeNameTextBox
Tip: Each service type shall be uniquely identified by exactly one service type name (see ECSS-E-ST-70-41C 5.3.1.a)

ServiceTypeDemandsThatAllSubserviceProvidersAreHostedInASingleProcess
Tip: Demand that all subservice providers in Service Type are hosted in the same application process

EnforceOrdinalNumberViewCheckbox
Tip: Enforce the exact chapter number in documentation.

EnforceOrdinalNumberViewTextBox
Tip: Enforce the exact chapter number in documentation.

ServiceTypeIDNumericUpDown
Tip: Each service type shall be uniquely identified by exactly one service type identifier that is an unsigned integer greater than or equal to 1, and less than or equal to 255 (see ECSS-E-ST-70-41C 5.3.1.b)

ServiceTypeButtonRemoveOrphaned
Tip: Remove message types unassigned to any Capability Type

Opus2 Population Tool Subservice Type view

SubserviceTypeGeneralTab
Tip: General information about Subservice Type

SubserviceTypeObservablesTab
Tip: Observables are on-board parameters that are provided by the related subservice (see ECSS-E-ST-70-41C 5.3.2.f)

SubserviceTypeSystemObjectTypesTab
Tip: System Object Types referenced by Subservice Type

SubserviceTypeNameTextBox
Tip: Each subservice type shall be uniquely identified by exactly one subservice type name (see ECSS-E-ST-70-41C 5.3.2.b)

SubserviceTypeOriginComboBox
Tip: Whether the subservice type is a standard subservice type or a mission specific subservice type

SubserviceTypeAllowsMultipleSubserviceProviderRealisationsWithinASingleServiceCheckBox
Tip: For each subservice type, whether multiple realizations of that subservice type are allowed within a single service shall be declared when specifying that subservice type (see ECSS-E-ST-70-41C 5.3.2.b)

SubserviceTypeRealizationIsPartOfTheInclusiveOrServiceDependencyCheckBox
Tip: Is the subservice type a part of an inclusive or dependendcy which requires at least one of the subservice types to be implemented for the given service type

SubserviceTypeRealizationIsRequiredByTailoringCheckBox
Tip: Whatever subservice is required or optional (see ECSS-E-ST-70-41C 5.3.2.d)

SubserviceTypeAddObservableButton
Tip: Add new observable

SubserviceTypeSystemObjectTypeAddButton
Tip: Add new reference to System Object Type

Opus2 Population Tool Capability Type view

CapabilityTypeGeneralTab
Tip: General information about Capability Type

CapabilityTypeCustomRequirementsTab
Tip: Custom requirements for documentation

CapabilityTypePrerequiredCapabilitiesTab
Tip: List of required Capability Types (see ECSS-E-ST-70-41C 5.3.4.b)

CapabilityTypeImpliedCapabilitiesTab
Tip: List of implied Capability Types (see ECSS-E-ST-70-41C 5.3.4.b)

CapabilityTypeExcludedCapabilitiesTab
Tip: List of excluded Capability Types (see ECSS-E-ST-70-41C 5.3.4.b)

CapabilityTypeImplementationTab
Tip: Implementation of Capability Type

CapabilityTypeNameTextBox
Tip: Name of Capability Type

CapabilityTypeShortNameTextBox
Tip: Optional short name of Capability Type used in documentation

CapabilityTypeIsSpecifiedWithAMinimumApplicabilityConstraintCheckBox
Tip: A "minimum" applicability constraint means that each related subservice provides that capability (see ECSS-E-ST-70-41C 5.3.4.b)

CapabilityTypeIsSpecifiedWithAByDeclarationApplicabilityConstraintCheckBox
Tip: A "by declaration" applicability constraint means that for each related subservice, whether that capability is provided by that subservice is a decision to take when specifying that subservice (see ECSS-E-ST-70-41C 5.3.4.b)

TransactionComboBox
Tip: Transaction type (see ECSS-E-ST-70-41C 5.3.5.1.b)

AutonomousTransactionTypeTriggerTextBox
Tip: Textual description of conditions triggering the autonomous transaction

Opus2 Population Tool Capability Type requirements view

Opus2 Population Tool Capability Type implementations view

Opus2 Population Tool Request Type view

RequestTypeTitleTextBox
Tip: Name of Message Type (see ECSS-E-ST-70-41C 5.3.3.1.a)

RequestTypeMessageSubtypeIdNumericUpDown
Tip: Message Type subtype identifier (see ECSS-E-ST-70-41C 5.3.3.1.c.2)

RequestTypeOriginComboBox
Tip: Origin of Message Type (see ECSS-E-ST-70-41C 5.3.3.1.c.d/e/f)

Opus2 Population Tool Request Type condition view

OnBoardConditionIsAnEndOfExecutionPostConditionCheckBox
Tip: The pre-conditions to verify prior to starting the execution of each request(see ECSS-E-ST-70-41C 5.3.5.2.3.a)

OnBoardConditionIsAStartOfExecutionPreConditionCheckBox
Tip: The post-condition to verify at the end of the execution of each request (see ECSS-E-ST-70-41C 5.3.5.2.3.f)

Opus2 Population Tool Request Type argument view

RequestTypeArgumentGeneralTab
Tip: General information about Request Type Argument

RequestTypeArgumentTitleTextBox
Tip: Name of argument

RequestTypeArgumentPresenceTab
Tip: Configuration of presence of Request Type Argument

FieldDataTypeChoiceControlFilterTextBox
Tip: Filter Field Data Types by name

Opus2 Population Tool Instruction Type view

InstructionTypeGeneralTab
Tip: General information about Instruction Type

InstructionTypeTitleTextBox
Tip: Each instruction type shall be uniquely identified by exactly one instruction type name (see ECSS-E-ST-70-41C 5.3.3.2.c)

InstructionTypeCanCauseTheGenerationOfMultipleNotificationsCheckBox
Tip: Whether a realization of that instruction type can cause the generation of multiple notifications (see ECSS-E-ST-70-41C 5.3.5.2.2.b)

AllowsMultipleInstructions
Tip: Whether that request type provides a single instruction slot or multiple instruction slots for that instruction type (see ECSS-E-ST-70-41C 5.3.2.d)

InstructionTypeRequiresAllInstructionsAreValidBeforExecutionOfTheRelatedRequestCheckBox
Tip: Whether the subservice verifies the suitability of all instructions contained within each request of that type before authorizing the start of execution of that request (see ECSS-E-ST-70-41C 5.3.5.2.3.c)

InstructionTypeRequiresAllInstructionsOfARequestAreExecutedInOrderCheckBox Tip: Whether all instructions shall be executed in the same order as the one in the request

InstructionTypeInstructionCountNameTextBox
Tip: Name of the field with number of instructions for documentation

InstructionTypeGeneralizationConditionTextBox
Tip: Condition indicating the presence of the given generalizing instruction type within a request

InstructionTypeInstructionsAllowedToBeUsedConjunctionTab
Tip: List of instruction types which can be used together with the current instruction type within the same request

Opus2 Population Tool Instruction Type condition view

InstructionTypeRelatedOnBoardConditionIsAnEndOfExecutionPostConditionCheckBox
Tip: The post-condition to verify at the end of the execution of each instruction (see ECSS-E-ST-70-41C 5.3.5.2.3.e)

InstructionTypeRelatedOnBoardConditionIsADuringInstructionExecutionConditionCheckBox
Tip: The condition to verify during the execution of each instruction (see ECSS-E-ST-70-41C 5.3.5.2.3.d

InstructionTypeRelatedOnBoardConditionRefersToAStartOfExecutionPreConditionCheckBox
Tip: The pre-condition to verify prior to starting the execution of each instruction (see ECSS-E-ST-70-41C 5.3.5.2.3.b)

InstructionTypeRelatedOnBoardConditionMustBeVerifiedForAllInstructionsOfThatTypeContainedWithinEachRequestCheckBox
Tip: Whether all instructions must be valid before the start of execution of the request

Opus2 Population Tool Instruction Type arguments view

InstructionTypeArgumentGeneralTab
Tip: General information about InstructionTypeArgument

InstructionTypeArgumentTitleTextBox
Tip: Name of the argument

InstructionTypeArgumentPresenceTab
Tip: Configuration of presence of Instruction Type Argument

FieldDataTypeChoiceControlFilterTextBox
Tip: Filter Field Data Types by name

Opus2 Population Tool Report Type view

ReportTypeTitleTextBox
Tip: Name of Message Type (see ECSS-E-ST-70-41C 5.3.3.1.a)

ReportTypeMessageSubtypeIdNumericUpDown
Tip: Message Type subtype identifier (see ECSS-E-ST-70-41C 5.3.3.1.c.2)

ReportTypeOriginComboBox
Tip: Origin of Message Type (see ECSS-E-ST-70-41C 5.3.3.1.c.d/e/f)

Opus2 Population Tool Report Type arguments view

ReportTypeReportingDataTitleTextBox
Tip: Name of Reporting Data

ReportTypeReportingDataGeneralTab
Tip: General information about Reporting Data

ReportTypeReportingDataPresenceTab
Tip: Configuration of presence of Reporting Data

FieldDataTypeChoiceControlFilterTextBox
Tip: Filter Field Data Types by name

Opus2 Population Tool Notification Type view

NotificationTypeTitleTextBox
Tip: Each notification type shall be uniquely identified by exactly one notification type name (see ECSS-E-ST-70-41C 5.3.3.3.d)

AllowsMultipleNtifications
Tip: Report type provides multiple notification slots for that notification (see ECSS-E-ST-70-41C 5.3.3.3.e)

NotificationTypeReportSlotTypeProvidesMultipleNotificationsCheckBox
Tip: Notification type offers the possibility to have multiple notifications of that type inside a single report (see ECSS-E-ST-70-41C 5.3.3.3.e)

NotificationTypeNotificationCountNameTextBox
Tip: Name of the field with number of instructions for documentation

Opus2 Population Tool Notification Type arguments view

NotificationTypeReportingDataGeneralTab
Tip: General information about Reporting Data

NotificationTypeReportingDataTitleTextBox
Tip: Name of Reporting Data

NotificationTypeReportingDataPresenceTab
Tip: Configuration of presence of Reporting Data

FieldDataTypeChoiceControlFilterTextBox
Tip: Filter Field Data Types by name

Opus2 Population Tool Field Data Type Editor

Opus2 Population Tool Default Tailoring Editor

FieldDataTypesTailoringEditorFilterTextBox
Tip: Filter Field Data Types by name

FieldDataTypesTailoringEditorShowOnlyUntailoredCheckBox
Tip: Show only Field Data Types without tailoring

FieldDataTypesTailoringEditorGenerateTailoringsCommandButton
Tip: Generate tailorings for all Field Data Types

FieldDataTypesTailoringEditorSourceDefaultTailoringsCommandButton
Tip: Source tailorings for all Field Data Types from the default tailoring

Opus2 Population Tool Behaviour Editor Editor

Opus2 Population Tool Property Editor view

Opus2 Population Tool System Object Type view

Opus2 Population Tool System Object Type Property view

Opus2 Tailoring Tool

Opus2 Tailoring Tool allows to define application tailoring’s for model defined with Population Tool. This includes selection of services, subservices and capabilities to instantiate, the tailoring of all required DataTypes and creation of System Objects. Moreover Opus2 Tailoring Tool allows to instantiate ASN.1/ACN files for one selected application tailoring and to create TASTE interfaceview with behaviour models. This feature is foreseen as a facility during tailoring process.

Opus2 Tailoring Tool can be started from Space Creator or as a standalone application.

To start Opus2 Tailoring Tool from Space Creator select Tools from menu bar and then Opus2 -> Tailoring Tool.

To start Opus2 Tailoring Tool as a standalone program run the following command:

   Opus2.TailoringToolGui

It is also possible to start standalone application withing existing project without Space Creator. To do this run the following command from project directory:

   Opus2.TailoringToolGui opus2_model.xml opus2_options.xml

Opus2 Tailoring Tool usage screens

Opus2 Tailoring Tool Entity view

EntityViewTitleTextBox Tip: Top level entity relevant to the tailoring, grouping lower-level system elements (see ECSS-E-ST-70-31C)

Opus2 Tailoring Tool Application Process view

ApplicationProcessViewPrefixTextBox
Tip: Element of the space system that can host one or more subservice entities (see ECSS-E-ST-70-41C 3.2.3 / 5.4.2)

ApplicationProcessViewControlAPIDNumericUpDown
Tip: Application process identifier (see ECSS-E-ST-70-41C 5.4.2.1.c)

ApplicationProcessViewSystemObjectsTab
Tip: Interfaced system objects (see ECSS-E-ST-70-41C 5.4.3)

Opus2 Tailoring Tool Deployment view

DeploymentViewLaunchServiceDeploymentWizardCommandButton
Tip: Run the wizard to interactively select Services to deploy

DeploymentViewLaunchDataTypeTailoringWizardButton
Tip: Run the wizard to interactively tailor Field Data Types

GeneralTab
Tip: General deployment configuration

SubservicePropertiesTab
Tip: Values for the properties of the subservices selected in the tailoring

TypesTailoringTab
Tip: Deployment specific field data type tailoring

ServicesTab
Tip: Selection of services, subservices and capabilities for the given tailoring

Opus2 Tailoring Tool Deployment services to select view

Opus2 Tailoring Tool Deployment tailoring view

FieldDataTypesTailoringEditorFilterTextBox
Tip: Filter Field Data Types by name

FieldDataTypesTailoringEditorShowOnlyUntailoredCheckBox
Tip: Show only Field Data Types without tailoring

FieldDataTypesTailoringEditorGenerateTailoringsCommandButton
Tip: Generate tailorings for all Field Data Types

FieldDataTypesTailoringEditorSourceDefaultTailoringsCommandButton
Tip: Source tailorings for all Field Data Types from the default tailoring

Opus2 Tailoring Tool System Object view

SystemObjectTypePropertiesTreeView
Tip: System Object's property values

Opus2 Tailoring Tool System Object mass edit view

Opus2 Document Generator

Opus2 Document Generator allows to generate textual documentation for model defined with Population Tool. Opus2 Document Generator can generate Chapter 6, Chapter 8, Annex C and Annex D for ECSS-E-ST-70-41C document.

To start Opus2 Document Generator from Space Creator select Tools from menu bar and then Opus2 -> Document Generator.

To start Opus2 Document Generator as a standalone program run the following command:

   Opus2.DocumentGeneratorGui

It is also possible to start standalone application within existing project without Space Creator. To do this run the following command from project directory:

   Opus2.DocumentGeneratorGuiopus2_model.xml opus2_options.xml

Opus2 Document Generator usage screens

Opus2 Document Generator

ServiceTypesControl
Tip: Service type to select for document generation

DocumentElementsControl
Tip: Document element to select for document generation (see ECSS-E-ST-70-41C)

EntitiesTreeView
Tip: Entity to select for document generation

OutputTextBox
Tip: Output file of generated document

Opus2 Frontend Generator

Opus2 Frontend Generator allows to instantiate model created by Tailoring Tool as a TASTE project. The instantiated model contains all selected application tailoring’s. It has ability to generate model within existing TASTE project without override of existing part created by user.

To start Opus2 Frontend Generator from Space Creator select Tools from menu bar and then Opus2 -> Frontend Generator.

To start Opus2 Frontend Generator as a standalone program run the following command:

   Opus2.FrontendGeneratorGui

It is also possible to start standalone application within existing project without Space Creator. To do this run the following command from project directory:

   Opus2.FrontendGeneratorGui opus2_model.xml opus2_options.xml

Opus2 Frontend Generator usage screens

Opus2 Frontend Generator

FrontendGeneratorOutputDirecotry
Tip: Output directory of generated frontend

Opus2 Options

Opus2 Options allows to modify basic options needed for proper artifacts generation. It can be accessed from every Opus2 application by View -> Options menu. Opus2 Options are saved in the current opus2_options.xml file and can be shared by all the applications.

Opus2 Options ASN/ACN

OptionsWindowMainAsnTemplateFilePathTextBox
Tip: Path to the main ASN.1 template containing the common ASN.1 type definitions (default: /home/taste/tool-inst/lib/Opus2/opus2/data/ccsds-space-packet.asn)

OptionsWindowMainAcnTemplateFilePathTextBox
Tip: Path to the main ACN template containing the common ACN type encodings (default: /home/taste/tool-inst/lib/Opus2/opus2/data/ccsds-space-packet.acn)

OptionsWindowAsnTemplateFilePathTextBox
Tip: Path to the template containing application process (APID) specific ASN.1 type definitions (default: /home/taste/tool-inst/lib/Opus2/opus2/data/asnTemplate.asn)

OptionsWindowAcnTemplateFilePathTextBox
Tip: Path to the template containing application process (APID) specific ACN type encodings (default: /home/taste/tool-inst/lib/Opus2/opus2/data/asnTemplate.acn)

OptionsWindowAsnFileNameTemplate
Tip: Pattern for derivation of application process (APID) specific ASN.1/ACN file names (default: {{entityname}}-{{appname}})

Opus2 Options Frontend

OptionsWindowIvTemplateFilePathTextBox
Tip: Path to the template for generating Interface View XML file containing the logical architecture of the instantiated PUS C Frontend (default: /home/taste/tool-inst/lib/Opus2 opus2/data/ivTemplate.xml)

OptionsWindowUiTemplateFilePathTextBox
Tip: Path to the template for generating Interface View UI XML file containing the graphical layout of the instantiated PUS C Frontend (default: /home/taste/tool-inst/lib/Opus2/opus2/data/uiTemplate.xml)

OptionsWindowGenerateDummyFunctionCheckBox
Tip: Whether or not to generate a Dummy function which stubs all unconnected interfaces of the PUS C Frontend (can be used for quick prototyping)

OptionsWindowDummyFunctionNameTextBox
Tip: Name of the Dummy function (if generated) which stubs all unconnected interfaces of the PUS C Frontend (default: dummy)

Opus2 Options Document

OptionsWindowDocxTemplateFilePathTextBox
Tip: Path to the MS Word OpenXML .docx document used as a template for generating .docx documentation (default: /home/taste/tool-inst/lib/Opus2/opus2/data/PUS-C Standard Template.docx)

OptionsWindowGeneratePerDeploymentIcdCheckBox
Tip: Whether or not to generate, using ASN1SCC, ICDs from each of the generated ASN.1/ACN files

OptionsWindowAsnAcnInvocationPatternTextBox
Tip: Pattern for invoking ASN1SCC (default: -icdAcn {{outputdirectory}}/{{entityname}}-{{appname}}.html {{outputdirectory}}/{{entityname}}-{{appname}}.asn {{outputdirectory}}/{{entityname}}-{{appname}}.acn)

OptionsWindowCompilePandocFileCheckBox
Tip: Whether or not to invoke Pandoc after generating Pandoc documentation

OptionsWindowPandocInvocationPatternTextBox
Tip: Pattern for invoking Pandoc (default: -s {{outputname}}.txt -o {{outputname}}.html)

This target can be changed to PDF by setting Pandoc invocation pattern as:\ -s Template:Outputname.txt -o Template:Outputname.pdf -t html --css /home/taste/tool-inst/lib/Opus2/opus2/data/documentStyle.css --embed-resources --standalone

For this command to work additional package needs to be installed: wkhtmltopdf.

Opus2 Options SDL

OptionsWindowSdlStructureTemplateFilePathTextBox
Tip: Path to the template defining SDL process structure used for editing SDL behaviour sources when OpenGEODE is invoked directly from the Population Tool (default: /home/taste/tool-inst/lib/Opus2/opus2/data/skeletonStructureTemplate.pr)

OptionsWindowSdlStubTemplateFilePathTextBox
Tip: Path to the template defining SDL process stub used for editing SDL behaviour sources when OpenGEODE is invoked directly from the Population Tool (default: /home/taste/tool-inst/lib/Opus2/opus2/data/skeletonStubTemplate.pr)

Opus2 Options Router

OptionsWindowApidRouterTemplateFilePathTextBox
Tip: Path to the template defining SDL for APID Router behaviour, responsible for routing requests based on APID (default: /home/taste/tool-inst/lib/Opus2/opus2/data/apidRouterTemplate.pr)

OptionsWindowCapabilityRouterTemplateFilePathTextBox
Tip: Path to the template defining SDL for Capability Router behaviour, responsible for routing requests based on their type (default: /home/taste/tool-inst/lib/Opus2/opus2/data/capabilityRouterTemplate.pr)

OptionsWindowTelemetryPackerTemplateFilePathTextBox
Tip: Path to the template defining SDL for Telemetry Packer behaviour, reponsible for packaging responses into telemetry packets (default: /home/taste/tool-inst/lib/Opus2/opus2/data/telemetryPackerTemplate.pr)

OptionsWindowDecoderTemplateFilePathTextBox
Tip: Path to the template defining C for Decoder behaviour, responsible for application process (APID) specific TC/TM transcoding (default: /home/taste/tool-inst/lib/Opus2/opus2/data/decoderTemplate.c)

OptionsWindowPacketReceiverTemplateFilePathTextBox
Tip: Path to the template defining SDL for Packet Receiver behaviour (default: /home/taste/tool-inst/lib/Opus2/opus2/data/packetReceiverTemplate.pr)

OptionsWindowReportCollectorTemplateFilePathTextBox
Tip: Path to the template defining SDL for Report Collector behaviour (default: /home/taste/tool-inst/lib/Opus2/opus2/data/reportCollectorTemplate.pr)

Reference

Property Types

OPUS2 Property Types provides information on the Property Types available for use in System Objects.

Field Data Types

OPUS2 Field Data Types provides information on the Field Data Types available for use in packet fields.

System Object Types

OPUS2 System Object Types provides information on the available System Object Types and their properties.

Step-by-step Checklists

General

• Familiarize yourself with OPUS2 Introductory Demo and OPUS2 Complex Demo, including the provided Troubleshooting section.
• Make sure that ST[1] is provided - it's required by almost all Capability Types.
• Make sure that data is consistent between connected enumerations and choice field data types (if choice has connected enumeration, enumeration values and names have to be consistent with choice values names).
  • Both names and order shall match.
• It is recommended to provide system objects in Application System Objects.
• Make sure that System Object names and IDs are unique between System Objects in one System Object Type.
• Make sure that data is consistent between each System Object and Subservice Properties (for example parameters name are consistent between different System Objects).
• Start the field data type tailoring by re-using the default tailoring, and then adjust the types according to needs.
• Make sure that data provided in System Object and Subservice Properties Custom Type Values are compatible with ASN.1 grammar - e.g., lists of parameters, time (interval) definitions, ...
  • In particular, be mindful of using lower-case for values, replacing spaces with "-"in names (e.g., My Parameter 1 should be written as my-parameter-1).
• Make sure that APIDs are tailored consistently across all relevant Field Data Types and System Objects.

ST[1] Reqeust Verification

• Select all capabilities.
• Tailor the types using the default tailoring.
• Make sure that failure notice data and code items match.

ST[3] Housekeeping

• Select the desired Capability Types.
• Provide Memory System Objects (see ST[6] checklist for proper tailoring, make it consistent with ST[6] system objects).
• Provide Parameters System Objects.
  • Make sure that the memory name and address of each Parameter matches those in the Memory System Objects, applying ASN.1 value grammar rules.
• Provide HK structures System Objects.
  • Make sure that the Parameter names refered in the HK structures match those in the Parameter System Objects, applying ANS.1 value grammar rules.
• Provide Subservice Properties.

ST[4] Parameter Statistics Reporting

• Select the desired Capability Types.
• Provide Memory System Objects (see ST[6] checklist for proper tailoring, make it consistent with ST[6] system objects).
• Provide Parameters System Objects.
• Provide Subservice Properties.
  • Default parameter statistics definitions are defined via a list, using ASN.1 grammar, in the Subservice Properties.
  • Make sure that the Parameter names refered in the statistic match those in the Parameter System Objects, applying ANS.1 value grammar rules.

ST[5] Event Reporting

• Provide Event System Objects.
• Make sure that Severity is set to one of the supported values (see ECSS-E-ST-70-41C for more information):
  • informative,
  • low-severity,
  • medium-severity,
  • high-severity.

ST[6] Memory Management

• Select the desired Capability Types.
• Provide Memory System Objects (at least one).
• Make sure that if we provide raw memory BaseType is set to type Empty.
• Make sure that if we provide raw memory IsOffsetAddressable is set to true.
• Make sure that Alignment is set to more than 1 (this limitation stems from a modulo check in SDL, it may be removed in future releases).

ST[11] Time Based Scheduling

• Select the desired Capability Types.
• Provide Time Based SubSchedule System Objects.
• Provide Time Based Group System Objects.
• Provide Subservice Properties.

ST[12] On-Board Monitoring

• Select the desired Capability Types.
• Provide Memory System Objects (see ST[6] checklist for proper tailoring).
• Provide Parameters System Objects (see ST[20] checklist for proper tailoring).
• Provide Event System Objects (see ST[5] checklist for proper tailoring).
• Provide Parameter Monitoring Definition System Objects.
  • If validity checking is not peformed, still provide a dummy Check Validity Condition (this is a limitation of the current implementation, may be removed in the future).
• Provide Functional Monitoring Definition System Objects.
• Provide Subservice Properties.

ST[17] Test

• Select the desired Capability Types.
• Tailor the types using the default tailoring.
• Pay special attention to the consistency of APID related Field Data Types if on-board connection test is to be supported.

ST[19] Event Action

• Select the desired Capability Types.
• Provide Event System Objects (see ST[5] checklist for proper tailoring).
• Provide Event Action Definition System Objects (make sure that event-definition-ids in System Identifier Values are consistent with Event System Objects).
• Provide Subservice Properties.
• Pay special attention to the consistency of APID related Field Data Types.

ST[20] Parameter Management

• Select the desired Capability Types.
• Provide Memory System Objects (see ST[6] checklist for proper tailoring).
• Provide Parameters System Objects.
  • Make sure that the memory name and address of each Parameter matches those in the Memory System Objects, applying ASN.1 value grammar rules.
• Provide Subservice Properties.

Complex Demo

OPUS2 Complex Demo provides an overview of creating a complex application using the OPUS2 toolset.