Exchange linked data with the Digital Data Package

In the age of model-based systems engineering, digital threads and digital twins, companies need to link product information in different formats across domain boundaries and process phases in order to be able to assess the impact of changes and ensure traceability in the development process. Exchanging this information with suppliers requires a combination of different domain-specific standards to ensure that partners know what belongs together and how. These include, for example, ReqIF for the requirements, SysML and OSLC for the system models, FMI or FDX for describing the functional logic and the test cases, JT for the geometry, STEP AP 242 for the product structure, and VEC and KBL for the electrics/electronics.

A joint working group set up by the VDA and the prostep ivip Association has defined a new standard for data containers with the aim of standardizing the exchange of data that is linked across different domains. The Digital Data Package (DDP) builds on preliminary work such as the VDA guideline 4953-2 for technical data packages (TDP) and drawingless processes (ZLP), as well as the association's assessment of available standards. Unlike its predecessors, the DDP includes not only CAD data, structures, PMI, etc. but also requirements and topics such as verification and validation (V&V). This means that it takes account of the entire product development process along the V-model.

The DDP working group comprises user companies from a variety of different industries and software vendors and works closely with other working groups in the association that are responsible for the further development and implementation of standards such as ReqIF or JT. The group is planning to soon release its first recommendation for review, which will be published at the end of the year. The aim is to convert the data model used to link individual standards into an OMG standard.

Like other project groups in the association, the DDP working group is also facing the challenge of obtaining valid test data. Fortunately, it was able to make use of the association's Mars Rover data, which is being used for testing in a number of different projects. Boeing also provided the group with data from the Stratoliner, which can in the future be used to confirm V&V use cases.

Prototype for the requirements process

One of the members of the DDP working group is PROSTEP AG, which is actively involved in helping develop the new standard. As a result, we were able to develop an initial prototype for generating and processing DDPs on behalf of a major German carmaker. It was used to test the results from the working group using the requirements process as an example. We were also able to use our experience to help improve the data model. The OEM has agreed to share our findings with the entire working group.

During the development of the DDP tools, and in line with customer requirements, we initially focused on the exchange of requirements and system models in the early phase of development, which involves the qualification of suppliers and coordination of the requirements. For example, the prototype supports what is referred to as the HIS process, in which suppliers must state which requirements they can meet and which they cannot. 

In the absence of their own requirements management system, many of them have thus far supplied this information in the form of a Word or PDF document, which means it has to be entered manually. Transferring this information with the help of a DDP instead would provide a quick initial benefit because it could then be evaluated by machine.

At the automotive manufacturer in question, the prototype is not currently integrated in the PLM world or any other enterprise application, it is used on its own. The project managers place their files in a folder and start the DDP generator, which creates the folder structure, stores the files and creates the network of relationships between the files using the attributes from the neutral formats.

Machine-readable data model

A DDP is a PDF/A-3 or ZIP container that can be sent, versioned and archived like a normal document. It contains a folder structure with the files in the domain-specific neutral formats, supplementary documents and a machine-readable data model that describes how the data is linked so that it can be imported into the recipient's systems by machine. A kind of "package slip" in PDF or HTML5 format that has been derived from the data model provides an overview of the links between the data in a human-readable form. This was a key requirement for the new standard as it ensures that the recipients can understand the interrelationships without having to use the respective authoring systems.

The data model was created by the working group manually. It is a generic, reusable model of the interrelationships that were identified using the structure of the neutral files and certain attributes. The network of relationships and the "package slip" never include all the information that is, for example, contained in a ReqIF or SysML file but rather only a handful of key attributes. The data has to be imported into the respective authoring systems before it can be edited. Information on which formats with which attributes were taken into account for the data model can be found in the recommendations.

Most companies are not currently using IT systems that would allow them to create a cross-domain digital thread. In many cases, the relationships between the information objects are managed in Excel lists, or they can be found in the heads of the product managers who have compiled them much like hunter-gatherers. For the first time, DDPs offer them the option of creating a machine-readable network of relationships using the neutral formats. Companies that are already using a solution for the digital thread, such as PROSTEP's OpenCLM software, can read out the links together with the neutral formats and integrate them in the DDPs.

The advantage that DDPs offer is the end-to-end exchange of data, together with their links, in both directions between different organizations. The fact that the data from umpteen different applications can be packaged at the push of a button provides the disciplines and domains involved with an interconnected baseline that reflects the development status of the product at a certain point in time. Users can trace the information back to its source and easily identify the differences between two data packages. This makes significant increases in the efficiency of collaboration processes possible.