Stories

There will be a lot of fun and exciting adventures that you will go on in your professional career. I'm going to share some of mine to give you inspiration or to learn something new.

A Story About Digital Twins: The Intersection Between Design and Spacecraft Assembly.

Where to Start?

Building spacecraft or any large system can be daunting. A unique challenge that faces NASA or any organization which makes a lot of custom products or services is a lack of heritage or precedence. NASA's missions operate in environments that are some of the most inhospitable in the solar system. All engineers, managers, and stakeholders on a project naturally ask where do you start? One unique solution that engineers have developed is a digital twin. This twin is a representation or model of a physical system like a spacecraft. The representation lives in an environment with the same temperature, atmosphere (if available), gravity, pressure, or any other variable that needs to be modeled in the environment.

Who Cares?

While in theory you don't need a digital twin to represent data, in practice it is really helpful to do so. Depending on how your model represents data, simulations can be run that can be used to predict what may happen while a system is in production or operational. For example, if you have a digital twin of the power consumption of a Martian rover over its expected lifetime then you can model on which Sol the power may run out. This can help managers determine which type of charging system (nuclear, solar, etc) should be fit on the rover based on the requirements of the mission.

It can also help lower the risk of mistakes. For example, NASA lost a Mars orbiter in 1999 due to a conversion error between metric and imperial units even though management for assembler of the spacecraft was clearly informed that NASA only uses metric units. A digital twin could have implemented rules saying that imperial units inputted into the digital twin is forbidden.

How to Maintain?

The proverb "it takes a village to raise a child" could be applied to a digital twin. There are accountants, engineers of a variety of disciplines (software, mechanical, electrical, etc), managers of all levels, and stakeholders who are invested and interested in the digital twin of the spacecraft.

The real "parents" of the digital twin would be systems engineers as it's their job and responsibility to make sure that the digital twin captures all of the requirements that the actual spacecraft will perform while in orbit or operation.

Why Change?

The old adage "if it ain't broke don't fix it" can be applicable to the discipline of systems engineering. Traditionally systems engineers collect the requirements of the system or spacecraft in a document. This document has changed over the years from pen and paper to Excel but the process of putting the requirement into a document has been used for a very long time. There has been a push for Model Based Systems Engineering which means representing a system in a model. This model can be physical like how civil engineers model bridges before constructing the real thing, but at present these models have started to become more and more digital.

These digital twins are more helpful that documents since the data in a digital twin can be used to simulate, analyze, reason, and interpret mission requirements. Information typically in a document is just written words, illustrations, or animations. It's generally more difficult to translate data in a document into something a simulation engine like Matlab would need. Digital twins are often written in code like Python.

The real change to the discipline of systems engineering is the push for better programming and programmers rather than just scribes.

But Why Design?

Just like how some development teams don't interact or need designers, system engineers don't need them at all. A pitfall that emerges in any large inter-disciplinary team is siloing or people sticking to their team and only collaborating when it's needed.

Design is a way of thinking and as a way to effectively communicate and tell stories to stakeholders across stakeholders within a project. Some engineers regardless of discipline have put more time and effort into perfecting their craft rather than soft skills. This is where design comes in to help with developing an intuitive interface between a task, user, and result.

An application of design based engineering within student learning has shown an enhancement in student outcome. This study can be extrapolated to all forms of learning including learning on the job. For example, engineers of any discipline tend to operate in specialized teams which means that they get very good at their discipline. So while systems engineers can change to become better programmers it does not mean that they are good at or aware of other disciplines needed to assemble a spacecraft.

Design and the people who practice it on the other hand work in environments where they must be aware and learn what their stakeholder wants or needs in order to successfully perform their task. This means that infusing elements of design into systems engineering can lead to more collaboration across engineering disciplines which will increase the likelihood of a successful mission and naturally prevent silos from emerging in the project.

What Parts of Design?

Some people including myself when I first started learning about design, tend to focus on user interfaces. While that is important for telling an effective story, UIs come from gathering research on what matters to users, customers, or stakeholders. For example, the UI for a mobile app for a bank will look and feel different than the desktop or web app for the same bank. Designers are aware of the restrictions that a mobile device has over a PC.

The goal for designers is to bring a positive experience to their end users, customers, or stakeholders.

Strategy For Asking Questions

One way that designers gather more information about what they're designers for is by asking questions. There are a lot of different forms of data but two salient types of data are qualitative and quantitative data.

Qualitative data focuses more on qualities about a system like "how do you feel about using Excel to capture requirements?" While this is a powerful question, it is generally hard to quantify.

Quantitative data focuses more on capturing numbers about a system like "on average, how many times per day do you use Excel to capture requirements?" This question is generally easier to capture in a dataset, but may not capture how it feels to be a part of a system.

For engineers, especially systems engineers, who want to infuse parts of design into their work can find it important to ask qualitative and quantitative questions to management and other engineers before capturing a requirement blindly within a document or digital twin.

Forming Connections

So that's great that you started asking questions. It's kinda of like you're a detective trying to solve a mystery. An important realization for designers is how is all of this data connected together.

From my personal experience, some of the best designers I know are very good at forming connections between how parts of any system connect together and the people who maintain those parts. I feel that forming connections within and across organizations helps gives a holistic pictures on how a spacecraft can be assembled.

For most engineers and people working on a project, it can be very easy to get siloed into their work. Designers tend to form connections due to the nature of their work. Assumptions are used often in engineering and ideally these assumptions are tested before a spacecraft is in space.

Engineers who infuse parts of design into their work can know who and why they need to talk to someone in the project before blindly committing a requirement to a digital twin.

Useable Interfaces

It looks like you've now been asking some questions and forming some connections, but how do you use this for your job. A useable interface comes in to help with that.

For a designer that already captured scope of their interface through asking question and understands their core audience for the interface after forming connections, they can start with developing a UI which is reusable.

There are aspects to reusable UI such as consistent layout of information, intuitive interface for inputting and outputting data, and making an interface feel invisible to end users.

For systems engineers who are trying to represent and simulate data for a spacecraft while minimizing risk in operation, this is where the intersection between digital twins and design comes in.

Where Are We Now?

So the goal for systems engineers is to hopefully use a more intuitive and useable interface for assembling spacecraft.

When systems engineers use digital twins, most systems engineers model systems using a language called SysML or Systems Modeling Language. It a language built on top of UML or Unified Modeling Language which is used to model how a data within a database should be organized.

There are apps that can be used to visualize the latest version of SysML such as Tom Sawyer. These apps can be used to model and simulate complex systems like cars or spacecraft.

What Lies in the Future?

While digital twins created using SysML or Python are great at modeling and simulating data, a pitfall that they run into is verification. Verification in layman's terms is are we doing the right thing. The data inputted into a digital twin could be completely inaccurate or unuseful data.

For example, if the systems engineers at an automotive company is creating a digital twin for a Formula One sports car the requirements for that digital twin will be different than the requirements for a family van. SysML currently does not have a way to restrict systems engineers from inputting requirements into the digital twin and does not have a way to reason or interpret the data.

A digital twin that has a semantic reasoner or a knowledge based AI could have rules inputted into the system which will prevent or alert systems engineering if they are inputting requirements which violate the rules for a family van.

The product I helped work on which was built with design based principles from its inception called OML Vision allowed systems engineers to intuitively create digital twins while allowing them to run a knowledge based AI on their requirements. Use cases of the product are at NASA JPL and JAXA.