Extending the digital twin to on-board software

How can a child be the father of man?

William Wordsworth said “Child is the Father of Man”. It means that the personality of people develop right from the time of their upbringing in their childhood. And based on the quality of upbringing, the person inculcates good or bad personality at the latter stages of his life.

The same is applicable when building a software system. Before designing a complex software system, one needs to understand the software behavior from system perspective. Modeling a software system is a standard process in software development, i.e. to support development tasks or to test and verify software properties. This picture shows the defect vs cost ratio: defects cost more to resolve further on in the development process.

Essentially it all boils down to “optimizing the language for your modeling, not the modeling for your language”.

What does a Digital Twin have to do with all of it?

An executable Digital Twin of your code helps avoid these defects at a much earlier phase. Now you may be puzzled by what a Digital Twin even means and what it has to do with the software you are developing, right? Let me explain.

Understanding the Digital Twin –

• The vision of the Digital Twin itself refers to a comprehensive functional description of a component, product or software


• This includes capturing more or less all information which could be useful in all the current and subsequent development phases

Well, basically creating a Digital Twin of your software code is based on left-loading principle (left being earlier in the development lifecycle) where we do more upfront in order to make architecture consistent and get a bigger payback during the later lifecycle phases. And this is one of the key benefits of model-based software engineering (MBSE).

• The software digital twin federates the concepts of Architecture and test driven development, Requirement driven test and verification and contract based design. User can build an abstract model architecture which is bound by contracts and do a formal analysis on them early in the design to check consistency. Thus created abstract model of the code acts as a digital twin and serve as implementation contract, to support further development and testing activities.

• Abstract model abstractions are removed at subsequent steps and enriched with executable contents directly, thus bridging the gaps between modeling and coding phase. Contract based design is always enforced which helps developers develop code which is always right by design. Test and verification activities are also mandated by the implementation contracts and any failed conditions are reported.

• Use of such digital twin also makes sure that all the changes are tracked effectively and work items across different teams are synchronized and consistent.

A use case perhaps.. An ACC one!

Let us take an adaptive cruise control as an example. There is one unit which computes safe distance between ego vehicle and leading vehicle. One example of capturing high-level specification in this case would be to say “under every condition if the ego vehicle speed is 2 m/s more than the leading vehicle speed that should mean that the ego vehicle is always at a safe distance with respect to the leading vehicle”.

http://www.orangenewsonline.com/2015/08/motoringtop-10-cool-tecnology.html

To model the above scenario, we have used here what you see as a “block interface” which is a unit piece of a bigger architectural design. The high-level specification is represented in form of a “contract”. Thus represented contracts need to be satisfied at every layer of software development process; from architecture design analysis to development of code to testing and verification to closed-loop virtual simulation with plant models

Bringing it all together..

In software development process, the Digital Twin –

• Bridges gap between modeling and coding and ensure that the model is at a different levels of abstractions to the code


• Gives insights at the model level which the code does not


• Enables user to do more in the model and less in the documents – provides users with right abstraction and projections to make understandability easier

But how does it help your team and processes –

• As a business owner, this brings more economical benefits as it allows you to specify the high-level business specification upfront and minimize the testing time and cost.

• As a project architect/project manager you can set the boundary conditions/contracts for developers and test engineers such that the developers have no choice but to deliver good code which meets specifications (boundary conditions/contracts).

• Development and test engineers are relieved from repetitive work for testing and verification. Every hour saved for manual testing can be better spent in functionality development or quality improvement.

Want to learn more?

Read the white paper

Check out other blog posts on model-based software development