The Value of Simulating Systems with IoT Software and Data in the Loop

Written By: Hedley Apperly
  • 1/26/2017

Many engineers are new to the Internet of Things (IoT) but still need to apply best practices for design and validation of the complex systems at the heart of this movement. Read on to find out how they can use model and system simulation to identify and fix problems early on, and also validate that a built product meets the original requirements and performs as expected.

Getting stakeholder buy-in

Modeling IoT systems offers new opportunities to simulate smart products before prototyping so that mashups, applications and data connections can be tested before software and sensors are built. Modeling an IoT system and then visually simulating the model helps stakeholders understand the proposed design and any issues, and agree the solution.

Assume a manufacturer has designed an electric truck using Windchill Modeler. The model is a digital representation of the truck’s parts, the context and services the truck provides. It also represents the functions, physics and algorithms associated with the engine, batteries, and other key system components.

InWindchill Modeler SySym, an engineer can create a simulation that shows a walk-through of the model. For example, the engineer could show the truck driving around the streets of New York City on a planned route. During this simulation, the truck could be shown accelerating and braking, allowing stakeholders to see how much energy is used and how much energy remains in the battery. By also seeing the truck’s speed, they could determine the range of the electric truck. They could even zero in on functions such as the performance of the tires on the road. In other words, they can see any visual representation of the underlying model.

This type of simulation helps stakeholders better determine if the system is – or is not – performing as expected. Perhaps the simulation shows that the truck only made it a few miles before running out of energy. With this information, the team could redesign the system before moving forward.

In addition, the simulation enables engineers to validate their IoT app interface. The data created by the simulation – such as the truck’s location, its speed and more – can be sent to the Thingworx cloud to be displayed in a dashboard interface. This allows engineers to get a sense of the data that would be displayed in the actual IoT app user interface before creating any code or prototypes.

Validating real-world performance

Once a prototype or product has been built, real sensor data can be fed back into the original simulation to validate that the system is performing as expected. By gathering data and comparing it with the original model, engineers can compare real-world performance against original assumptions and analysis.

By comparing real data with early designs for performance-based analysis, manufacturers can determine if a product is performing as expected and whether the digital model is a good representation of the real world for future designs. If the model isn’t up to par, the engineers can adjust the model and rerun it.

In the case of the electric truck, perhaps the data comparison shows that the model is somehow deficient. The engineers could decide to set a lower torque limit within traction control while also adding humidity to the environmental factors displayed in the interface. This would help continually improve both the model and the product.

This closed-loop approach offers many benefits. It allows organizations to simulate products very early in the engineering lifecycle, and secure stakeholder buy-in to the design of their IoT systems. It even makes it possible to use real product data to improve future simulations and actual products.

  • Windchill
  • PLM
  • Electronics and High Tech
  • Predictive Analytics

About the Author

Hedley Apperly

I am a VP of Solution Management at PTC. I have an HNC in engineering, a 1st class BSc in computing & an MA in strategic marketing. I am an author and visionary on methodologies, modeling and reuse. I am also a member of the OMG Board & OASIS OSLC Core committee. I was involved in writing Component Based Development for Enterprise Systems (1998 Cambridge University Press). I also co-authored Component Based Software Engineering; Putting the Pieces Together (1999, Addison-Wesley) and Service- and Component-based Development; Using the Select Perspective and UML (2002, Addison Wesley.)