Hardware and Software Co-Exist Due to Model-Based Software Development

As we discussed in the last post, more software is making its way into traditional mechanical products, and organizations need to find new and innovative ways to deliver quality products within strict time constraints. Software and electronics are taking over everyday items, from household products to cars. Many smart products need to process copious amounts of information in real-time. Generic computer processors aren’t cutting it anymore because they can’t run the computations you need for control systems and smart features in real time. To solve this problem, companies are creating more integrated chips (ICs).  The cost for ICs is coming down, but they take a long time to make. How can companies accelerate the process?

The Case for Model-Based Software Development

Model-Based Software Development is a new approach that tackles this concern. It focuses on creating virtual representations throughout the development process, instead of waiting until the end to make sure everything works. This process is also called “X-in-the-Loop.” It’s a step-by-step approach for ensuring your software and hardware co-exist peacefully. You begin with basic software models and work your way up to running mechanical and software simulations together.

X in the Loop

Model-in-the-Loop (MiL): This is the first step. You create a UML model which serves as the underlying logic diagram for your software and connect it to a 1D simulation on the mechanical side. They form a closed loop with the software model sending signals to the mechanical simulation and virtual sensor readings go back to the software model. This should exhibit the control intended. How does it communicate with the physical form of the product? Is it doing what you need it to do?

Software-in-the-Loop (SiL): Engineers use the software to model generates compiled code. You connect this code to the mechanical simulation and verify that the behavior is the same. You’ll typically use an emulator for the electronic system where you’ll run your software.

Processor in the Loop (PiL): Here, you embed or flash your software onto the prototype integrated chip (IC). That physical IC is then connected to the digital simulation of your mechanical hardware. Again, you see if it’s acting the way you want.

Hardware in the Loop (HiL): With this step, you embed or flash your software onto the prototype board system that includes your IC. This embedded system is connected to the digital mechanical simulation. You verify behavior again.

So, remember those anti-lock brakes we talked about last time? You could use this type of modeling to simulate different environments. The UML model checks for sliding conditions. You can send the two signals that disagree to the UML model which is connected to your brake system and you watch what happens. Does the model send a message to start automatically actuating the brakes? If it doesn’t, you need to go back and debug the software.

The advantage of using this system is somewhat similar to sprints in Agile, which we discussed in a previous post. If anything fails, you’ll know where things went wrong. You’ll have to fix it before moving on to the next development phase, as opposed to waiting nine months to test the completed integrated chip.

Verifying Integration

Organizations can’t wait nine months to start verifying that software runs correctly on target electronic hardware. As the demand for more electronics in traditional products grows, schedules will only get tighter. The solution is to not wait: start verifying everything digitally. Make use of software models and run them with simulations. For the software models, the coders can sit down and make diagrams that show different components in the system, what they do, and how they connect with others. If there’s an issue during development, you’ll have a better idea of where things went wrong.

Summary

How can engineering companies make their development processes more efficient? Because more software is being jam-packed into traditional products, engineers face the additional challenge of getting brand new software to run on custom hardware. Instead of waiting until the very end of the development cycle to verify that everything works, the X-in-the-Loop process breaks things down into more manageable parts. It’s sure to save a lot of headaches in the end.