Efficient Engineering 101 (II): Document-Driven vs. Data-Driven Systems Engineering (DDSE)

Did you know that most satellites are being built with Excel? Or that engineers spend 86% of their time updating documents and searching for information? It’s about time to approach the way of engineering from a different angle.

In complex hardware engineering projects, there are usually three different kinds of engineering data that must be maintained throughout the entire development cycle: CAD Data, Simulation Data and your actual engineering values, such as mass and power consumption. The challenge is, that among others, high accuracy, correctness and traceability of the engineering data is necessary to succeed with your project.

However, whereas new data can be generated easily with the help of Word or Excel, different CAD or simulation or even model-based systems engineering (MBSE) tools in every engineering stage – it requires some effort to manage and maintain the data. As a result of the absent single source of truth which would keep the data consistent, there is a high chance of creating inconsistencies in your documentation every time you have to manually update or forward it via email to inform your colleagues about recent changes.

This article focuses on different approaches in managing data to facilitate the systems engineering activities and gives an introduction to the principle of data-driven systems engineering. Compared to traditional document-based engineering, this novel principle can reduce your project’s development time and costs by up to 15%.

Document-Driven Systems Engineering

In traditional systems engineering, the resulting engineering data of each development stage is being stored in documents, spreadsheets and other files. These documents become very important to the entire engineering project, because they represent the current status of the development, serve as input for the next engineering phase and will be used to communicate with stakeholders.

In other words, documents are reports on one specific status of development. Whenever the focus of the engineering process is to create documents that define the system at the end of each stage, this can be called “document-centric” approach of engineering [1]. All engineering activities will lead towards creating new documents to store more data within them.

“Document-centric” is the term applied to the approach used where the document author(s) directly enter the information into the end-product, whether a physical document, a word processing package or a model of a document in a MBSE tool.” [1]

Some engineering teams which are applying MBSE methodologies are trying to reduce the number of documents. But since the “model” of a product cannot be viewed directly by humans, documents as “written reports on the models” remain part of the process – esp. for communicating with stakeholders, reviewing, and whenever evidence in the form of officially “signed” documents is required. [2]

There are two main problems with this document-driven approach of engineering, that should be pointed out:

  • First, by manually transferring the engineering data e.g. from your simulation tool into your document, the engineering data becomes static. It disconnects from the source of creation, e.g. the simulation, and usually remains disconnected from all the other engineering values, e.g. the inputs for your simulation. Adjustments and updates on data have to manually be passed on to documents. As a result, the traceability of your data and associated calculations and other manipulations is lost.

To give an example, to manage CAD data, you may use PLM/PDM systems that highlight the most recent version of your model and provide version control functionalities. However, how can you effectively manage engineering values? By using document management or file storage tools like Google Drive, one problem remains: your (engineering) data remains disconnected. Once you change a value that has been used for calculating another value, you’ll need to manually propagate the changes throughout all of your files.

Data-Driven Systems Engineering

Instead of creating documents to report the current state at the end of each development phase, like in document-centric approaches, Data-Driven Systems Engineering (DDSE) focuses on working with data points usually within a single source of truth.

Single source of truth means that every data point is created, used and stored in a single database. You can then use reference links, similar to desktop shortcuts, to access these data points in other places. 

Valispace is an example of a single source of truth for engineering data. To facilitate a data-driven systems engineering approach, this engineering data can be accessed in real time by the use of our collaborative web-based tool, which does not require a installation or a specific platform to run. 

Within such tools, a “DDSE engineer” can access the database from anywhere at any time and is able to create, use, store and manage engineering data. It is not necessary to duplicate any data, since these tools allow for referencing any data point at any time and any place.

Additionally and similar to data-driven software processes [3], DDSE can also be described as a principle, where the DDSE engineer would base his decisions on the single source of truth data. The engineer has a full overview of the project data and its latest changes and can, therefore, make decisions and trade-offs with all the relevant information in real-time. All data will be consistent throughout the entire engineering cycle. This will also facilitate the broader use of MBSE tools in hardware engineering.

All technical properties are stored in one consistent database with formulas connecting these properties. The connection between properties sets the proposed tool apart from current document-based solutions, as it ensures rapid visualisation of parameter dependencies and clear views on how design changes affect the whole system.” [4]

Moreover, any alteration of the engineering data will automatically be propagated throughout the entire database. That means engineering values, tables, visual mass budgets, connections graphs, requirement verifications and simulations will automatically always be up-to-date.

In Valispace, these changes are additionally made visible by instant push notifications. As a result, engineers won’t need to go to colleagues every now and then to request information about the latest changes.

As mentioned above, reports are useful means to communicate with stakeholders. However, contrary to the document-driven approach, the engineering data will be included as a reference link in the reports of data-driven systems engineering tools. In other words, the report will automatically always represent the current state of development, similar to services like Google Docs. Another advantage of these dynamic reports and dashboards is that they can easily be shared with stakeholders in real-time.

Conclusion

Document-Driven and Data-Driven Systems Engineering are engineering philosophies – it lies within the hands of the engineering teams to choose the way they want to work.

Whereas the document-centric approach has been an approved workflow in the history of the engineering activities, a data-driven approach presents an opportunity to reduce inconsistencies in engineering data and time spent on updating documents and searching for information to a minimum.

If you are interested to learn more about how this data-driven approach is implemented in Valispace, click here to try our software for free.

Stay tuned for our next blog articles!

[1] D. Harvey, P. Logan et al., “Document the Model, Don’t Model the Document”, SETE / APCOSE 2012 – Brisbane – May 2012, Aerospace Concepts Pty Ltd

[2] P. Logan, D. Harvey et al., “Documents are an Essential Part of Model Based Systems Engineering” – 2012 – INCOSE

[3] W. Maalej, M. Nayebi et al., “Towards Data-Driven Requirements Engineering”, in: “Future of Software Engineering”, 2015

[4] L. Lindblad, M. Witzmann et al.,“Systems Engineering from a web browser: turning MBSE into industrial reality”, SECESA 2016