How many EDS formats do you need to plan a spacecraft? Possible ways towards standardization

Abstract

A lot of different parties have to communicate and exchange data with each other during the lifecycle of a spacecraft. One example we are looking into is the usage of information from manufacturers in CE studies during the planning phase of a spacecraft. Currently, information from manufacturers is usually offered as a PDF file that describes the technical features of a component. This information must then be entered manually in an MBSE tool by an engineer. That, and finding a fitting component for the mission requirements in the first place, costs time. It also is error prone due to typing mistakes for example. How about a system where an engineer can place a request and get a list of fitting components from different manufacturers - maybe even directly connected to the MBSE tool? To realize such a system, it is necessary that all manufacturers describe their products in a uniform and comparable way. Electronic Data Sheets (EDS) can be a way to realize such a uniform description - not only for the described use case but for many more. A uniform automatic exchange of information about spacecraft components is also relevant in other (also depends on?) phases of the lifecycle of a spacecraft, for example when testing manufactured components. For testing, a different view on the component is relevant. While during planning mass budgets are calculated and compared, for testing it is relevant to have detailed information about interfaces, protocols, and commands. Not only are different views relevant for different phases of the lifecycle but different categories of components have also different sets of relevant parameters. Frequencies for example are interesting for antennas but rather not for batteries. So, there will be neither one EDS that contains the information for one component in every phase of the lifecycle of a spacecraft nor one EDS format that fits all components categories at the same time. Still, for automated communication it is necessary to develop standards for the description of components - it just might not be one standard but a set of standards with a common vocabulary. To ensure the semantic compatibility between different EDS formats we think that ontologies can help. For example, one ontology can describe the semantics of a mechanical Interface Control Document (ICD) and another ontology can describe the semantics of an electrical ICD. But both ontologies can share common parts, in this example the description of the pins of an interface. In software engineering it became common to develop rather small applications that are linked together instead of a huge one that covers all use cases. We think that a similar approach also makes sense for documents and information exchange - to have small documents but a common language that enables different parties to talk with each other without having to understand each other’s domains fully. This concept also encourages the knowledge sharing and reusing the existing ontology.