Modeling embedded systems - Part 4: If prototypes aren’t possible -

Modeling embedded systems – Part 4: If prototypes aren’t possible

Editor’s Note: In Part 4 in a series of tutorials on modeling tools, Shelley Gretlein of National Instruments considers those situations when traditional hardware prototyping is not possible and how modeling can be a viable option.

Sometimes you must model – you simply can’t prototype or iterate on your design. Consider a project when perhaps the embedded system doesn’t exist – when you are designing for hardware that is not yet complete or ready, such as the latest chip where you are designing to specifications instead of silicon. This is a great example where modeling, simulation, emulation and later prototyping is a valuable approach.

One example is at National Instruments (NI) where they were designing for unreleased hardware. The embedded team needed to move a significant amount of their core product designs to a new MPU+FPGA+I/O architecture before the integrated silicon was on the market. They saw the value of this new technology early through confidential interactions with the silicon vendor. This early access allowed them to plan for the new technology upgrade in our embedded system. The engineers worked closely with the vendor throughout the entire process – an important point in such situations.

Throughout these discussions, the vendor did an excellent job of setting up a development platform for the NI embedded team to use as an emulation of what the final architecture would look like – including a fixed personality FPGA that would represent or behave like the final FPGA fabric in the eventual design.
This development platform (Figure 21 ) was a valuable board used for early prototyping, design, and test. However, it was certainly not an exact stand-in for the final product. There were several subtle and a few substantial differences. These discrepancies were well documented by the vendor so there were no surprises, but the engineers needed to optimize for and understand the substantial differences as they were developing, so there was still a bit of work to do.

Figure 21 – Example of a silicon prototype board (courtesy of LogicBricks) versus a final hardware design (NI CompactRIO courtesy of National Instruments).

The most important shortcoming of the development board was the fact that instead of a single, high-performance FPGA fabric like the final design, the engineers at NI were designing to a system with multiple FPGAs. The communication delay between silicon caused a significant performance degradation. The development board couldn’t replicate an entire system running at 40 MHz, but could only reach 10MHz, making it unusable for timing and testing accurate application performance. This is a good example where all models, even physical emulation platforms, aren’t 100% accurate, but if you understand the shortcomings, they are still very useful.

To compensate for the shortcomings of the model, the team chose to include a software-based design in the development. They first found off-the-shelf boards that had similar CPU characteristics in terms of performance and architectures (multicore ARM designs that were close to the final design) and that provided performance comparable to the final product. This hybrid design approach provided a closer system in terms of floating point performance.

To accommodate the FPGA design aspects, the team designed a software-based environment on the real-time CPU that allowed the deployment of FPGA code to a real-time target and have it behave similarly, in terms of timing, to the final FPGA fabric that would then be cross-referenced with the slower, more accurate FPGA combination board from the vendor.

It's important to note that the team chose not to simulate the entire hardware platform using cycle- or even instruction-accurate simulation tools. They deemed “stand-in” hardware platforms with sufficiently similar characteristics as “good enough” and the most efficient approach for development. The team was confident in this approach because they knew once real silicon materialized, the final implementation could leverage the early design and full test frameworks as developed on the hardware stand-ins.

If you find yourself in a similar situation, designing for a target that isn’t in the market yet, you can approach your design in a similar fashion.

  • Work closely with your vendor to understand what features and capabilities the future platform will have and to understand the differences in performance and hardware architecture
  • Select an existing, off-the-shelf, similar platform for early design and development
  • Once you run into the performance or feature limitations of that existing platform (the areas where the new design will differ and add more value) then select a surrogate hardware and software emulation platform for designing to those new, unreleased capabilities. This step requires additional software work to create the simulated or emulated environment.

Even with these well-planned steps there will be differences and there will be additional development once you get your final hardware device. But if you focus on proper design techniques and clear abstraction boundaries, you can protect large portions of your algorithms and focus on optimizing timing and specific I/O features once you get your first prototypes up and running.

Related to the silicon being unreleased, perhaps you can’t prototype because of the size or cost of the project. If you are creating a new control system for a new light rail system, for example, you can’t work on the prototypes until late in the game – and you certainly don’t want to experiment on the real thing. These are situations where software models can be very helpful.

But aren’t All Models Wrong?
“All models are wrong, some are just useful” is a phrase generally attributed to statistician George Box. Whether you are new to modeling or have been designing embedded systems for decades, this warning pertains to us all. No matter how carefully or completely you might model a system, the model will always be less than the reality that is modeled.

You may remember when Boeing’s 787 Dreamliner was introduced. This aerospace innovation was one of the most exciting technology introductions in modern times. The mid-sized, twin-engine jet airliner developed by Boeing Commercial Airplanes is comprised of 50% composite (carbon fiber), 20% aluminum, 15% titanium, 10% steel, and 5% other materials but in terms of volume, the aircraft is 80% composite. Each 787 contains approximately 35 tons of carbon fiber reinforced plastic.

What does this have to do with modeling? Paolo Feraboli, an assistant professor at the University of Washington School’s Automobili Lamborghini Advanced Composite Structures Laboratory (“Is the carbon fiber 787 dreamliner safe enough to fly?” ), was extensively involved in the Dreamliner design and had this to say about modeling the 787: “Unlike homogeneous metals, multi-layered composites are very difficult to simulate accurately on a computer. We don’t currently have the knowledge and the computational power to do a prediction based on purely mathematical models.” Thus new, innovative materials require modeling AND prototyping in order to be designed and tested.

Figure 22 – Boeing's 787 Dreamliner was so innovative in terms of material, the embedded designers needed to model AND prototype to truly understand the behavior of the design.

This doesn’t mean models are useless. If done well, you can use models to help in all of the situations covered in this series. You just don’t want to use only models for your embedded system design.

From the examples, you understand how useful models are and then we tell you they are all wrong – what are you to do? You embrace another useful quote from author Jim Collins, embrace “the genius of the and”. You must model your system AND combine it with the ‘real world’. Often the best way to combine your theories and requirements with the real world is to create a prototype.

This approach – modeling, simulation, and prototyping – is also critical in complex mechatronics systems such as robotics. Fred Nikgohar, CEO of Robodynamics, points out the value of the real world. Since building robots is about managing a multi-disciplinary project, it involves not just software but mechanics, electronics, and integration: “Integration is often the after-thought in building robots. It is that final step in the design process where all the disciplines come together and create a robot greater than the sum of its engineered parts. It is also the step where things that worked in isolation often fail. And worse, troubleshooting becomes enormously more difficult because if the robot doesn’t behave as planned, you have to troubleshoot throughout the engineered chain…”.

He points out the challenge in robotics is a lot of ideas that never come to fruition. “The real world is… very real! Wires come loose, mechanical parts bend, even firmware uploads fail sometimes. By sheer necessity to create robot engineering efficiencies, we have developed testing plans, troubleshooting plans, and even simulation runs to make things go further and smoother. But nothing has been more valuable than the actual experience of building robots.” This applies to all of our embedded system design. Nothing is more valuable than experiencing your design with real-world constraints and real-world situations. You must model and prototype to perfect your design.
To model and create a prototype, you need a hardware prototypingplatform. Prototyping platforms are composed primarily of commercialoff-the-shelf components configured to meet the I/O specifications ofthe system and provide a quick, seamless way to connect the controlmodel with real-world I/O, making it easier to test and iterate thedesign.

As shown in Figure 23 , the controller design istested in a real-time environment and connected to actual hardware. Thisprovides excellent verification and validation feedback on the fidelityof the modeling effort and the resulting control design early in thedesign flow. Further refinements to the controller and hardware designsand requirements can be made prior to finishing the design of theproduction systems.

Figure 23 – The design V integrates simulated and real-world I/O to be most effective.

Beyondgetting your system up and running before you have your final hardware,there are other reasons you should focus on getting to your prototypequickly. If you’re in an innovative space, prototypes allow you failearly and inexpensively. Real innovation always includes a risk offailure. Thomas Edison once joked, “We now know a thousand ways not tobuild a light bulb.” By building a prototype, you can quickly weed outthe approaches that don’t work to focus on the ones that do.

Prototypesalso help you technically to understand the problem. By developing afunctional prototype sooner rather than later, you are forced to addressboth the foreseen and the unforeseen technical challenges of a device’sdesign. Then, you can apply those solutions to a more elegant systemdesign and model as you move to developing the final deployed solution.

Theprototype can also help resolve conflicts. The best engineers havestrong opinions about how a given feature should be implemented.Inevitably, differences of opinion result in conflicts, and theseconflicts can be difficult to resolve because both sides have onlyopinions, experience, and conjecture to refer to as evidence.
Bytaking advantage of a prototyping platform, you can quickly conductseveral different implementations of the feature and benchmark theresulting performance to analyze the trade-offs of each approach. Thiscan save time, but it also ensures that you make the correct designdecisions.

Figure24 – Integrating hardware in the loop with your embedded control systemallows you to prototype sooner and results in higher quality designs.

Finally,prototypes can help you file patents more easily. Before 1880, allinventors had to present working models or prototypes of theirinventions to the patent office as part of the patent applicationprocess. Today, the patent office uses the “first to invent rule,” whichgrants a patent to the first inventor who conceives and reduces thetechnology or invention to practice. Though no longer required, aprototype is still the best and safest way to demonstrate “reduction topractice.”

You have your prototype – now what?
If youcan demonstrate or, better yet, put a prototype into the customer’shands and get real feedback on the value of your innovation, theprobability of business success greatly increases. This is especiallyimportant when you are working in an extremely innovative area where‘proving it’ means progressing on your project.

Loccioni Groupin Italy is one example of an innovative team that employs modeling,simulation, and iterative prototypes. Loccioni Group is considered aflag-bearer for Italian innovation because of its reputation fordeveloping custom technical solutions to ensure quality, comfort, andsafety. They focus primarily on two industries: automotive andelectrical appliances.

Loccionio Group embraced “the genius ofthe and” in a recent embedded test system – the Mexus project – formeasuring and charting the flow rate of diesel engine nozzles. Thisproject originated from the need to measure the flow rate of dieselengine nozzles with a detailed quantification of the fuel injectedduring a single injection. The final product is an instrument usedworldwide by injector manufacturers for end-of-line production tests.The goal was to provide a low-cost embedded product with betterperformance than any other instrument on the market.

Figure 25 – The injection chamber and its control system was modeled using modern graphical design tools.

LoccionioGroup designed a reliable product capable of accurately determining thetwo fundamental parameters characterizing injectors: the flow rateinjected for each shot and the chart of the instantaneous flow rate. Theinstrument provides the measurement of the fuel quantity injected ineach single shot event up to a maximum of 10 events per revolution (alsoknown as multi-injection). By simulating the engine operation at 3,000rpm, the readout value injection for each revolution can be easilydetected by the system, which provides the quantity of each fuelinjection in real time.

The innovative aspect of this project isthe calculus algorithm used in the solution. The system acquiresdifferent analog signals and processes them in real time, providing theuser with reliable test results up to the injector functioning rate of50 instantaneous values per second. The system is also able to determinehow much fuel is dispensed in each injection. This information issignificant for injector characterization because emissions regulationsare becoming more restrictive. Consequently, it is important to providemanufacturers with more detailed information to gain high-levelcombustion, reducing either fuel consumption or the quantity ofpollutant gas within the environment.

One critical element ofthe Mexus system is the injection chamber, the cylinder provided withcontrol sensors and valves where the fuel is injected and the specificmeasurements are performed. The injection chamber and its control systemwere modeled with graphical design and simulation software. In thisstage, simulations were also performed using the same graphical systemdesign environment. During prototyping, the same computer was maintainedthrough a data acquisition board that performed functionalcharacterization and validation. This important development stage of theproject highlighted the need for a more refined chamber injectionmodel. This was determined by using system identification software aspart of the same graphical system design tools, which made it possibleto obtain the transfer function of the injection chamber andconsequently design a suitable control algorithm.

To enable alarge scale deployment, Loccionio Group needed a hardware device withfailure-free technology that was capable of operating around theclock, offered a compact form factor, and was suitable for an industrialenvironment. They chose hardware that helped them make a quick shiftfrom prototyping to deployment and ensured they met the sampling raterequirements and the real-time, deterministic control of the process.

TheMexus final product guarantees the highest reliability in testoperations. The accuracy of the measurements is due to the introductionof innovative working methodologies that ensure test compliance with themost restrictive regulations. By employing modeling, simulation,prototyping and deployment techniques, Loccioni Group has provided theautomotive world with an innovative product that delivers excellent teststandards.

If you follow similar recommendations for yourdesign, you will have a prototype and an embedded model. You can thenoptimize, refine, and test the system. When all your individualcomponents and subsystems have been tested and validated, they arecombined and tested together to ensure that the original designrequirements are met.

In some cases, parameters in yourcontroller are finely tuned during this phase to meet original designrequirements. Although creating embedded models in your design processdoes not completely eliminate the need for testing, it offers severalopportunities to reduce the amount of test that will be required priorto the release of the production system.

Modeling designtechnology is currently evolving to aid in automating the final testingprocess. Early tool providers in this space automatically generate testvectors and execute scripted sequences to verify both models andautomatically generated code. Soon, these capabilities will extend tophysical tests and scripting test sequences, including real-world I/Oconnections, needed to verify all behaviors of the control system.

Creatinga model for your embedded system provides a time and cost-effectiveapproach to the development of anything from simple to incrediblycomplex dynamic control systems, all based on a single model maintainedin a tightly integrated software suite. Using modern modeling softwaretools you can design and perform initial validation in off-linesimulation. These models then form the basis for all subsequentdevelopment stages. As we have seen, creating models for your embeddeddesign provides numerous advantages over the traditional designapproach.

Using this approach combined with hardware prototypingyou reduce the risk of mistakes and shorten the development cycle byperforming verification and validation testing throughout thedevelopment instead of only during the final testing stage. Designevaluations and predictions can be made much more quickly and reliablywith a system model as a basis.

This iterative approach resultsin improved designs, both in terms of performance and reliability. Thecost of resources is reduced because models can be reused by designteams, design stages, and various projects, and because of the reduceddependency on physical prototypes. Development errors and overhead canbe reduced through the use of automatic code generation techniques.These advantages translate to more accurate and robust control designs,shorter time to market, and reduced design cost.

Part 1: Why model?
Part 2: Modeling examples
Part 3: Where to model?

Shelley Gretlein is the Director of Software Product Marketing at NationalInstruments. Currently focused on growing the application and success ofgraphical system design globally, Gretlein is responsible for thedevelopment strategy and worldwide evangelism of the LabVIEW softwareplatform including LabVIEW Real-Time and LabVIEW FPGA. She joinedNational Instruments in 2000 and holds a bachelor’s degree in computerscience and management systems as well as minors in Mathematics andFrench from the Missouri University of Science and Technology.

Thisarticle is based on material by Shelley Gretlein written for inclusionin “Software Engineering for embedded systems,” edited by Robert Oshana,to be published early in 2013 by Morgan Kaufmann, a division ofElsevier, Copyright 2013. Used by permission.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.