Evaluation And Development Of The Osra Interaction Layer For Inter-Component Communication

Ever increasing demands on the complexity of onboard software has led the European Space Agency to define the Onboard Software Reference Architecture (OSRA) to create a common framework for modeling onboard software for space applications. The first major version was released at the end of 2017 and provides the metamodel with additional documentation and a model editor. It enables the user to create a detailed high-level representation of an onboard software system, but leaves the choice of an execution platform and the generation of actual source code for it to the implementing party. The core philosophy of OSRA is to divide the onboard software into independent components with clearly defined interfaces and separate the functional and non-functional aspects of components. However, OSRA aims to cover a large range of applications and therefore provides a large variety of modeling artifacts for component interaction. While this gives a lot of design freedom to the software architect designing the overall software, it moves the responsibility of supporting all aspects and behavioral requirements correctly to the execution platform and interaction layer.In this study, we analyze the demands of OSRA towards the execution platform and necessary elements which have to be added or generated in order to support the multitude of different inter-component interactions. The results of the analysis are used to implement the first prototypical code-generation framework for OSRA models. The target execution platform for the code generators is the Tasking Framework, a reactive cooperative multitasking framework from DLR. It has successful flight heritage in numerous spacecraft projects and has also been the target of code generation from software models before. Nevertheless, many of the aspects discussed here apply equally to common priority-based preemptive multitasking frameworks. The analysis and the implementation both uncovered several issues where clarification in the OSRA metamodel description was necessary. We will discuss the additional constraints we introduced towards the metamodel in order to deal with these issues, which eases the generation of code skeletons and scheduling primitives. Finally, while this study concentrates on the inter-component interactions, we will also discuss further aspects currently missing from OSRA and which either need to be added by the implementing party or in a future revision.