Embedded systems design process: how traditional methods hold you back

Traditional embedded systems design processes: The Status Quo

Until recently, the process of developing, testing, deploying, and supporting embedded systems relied on access to the exact hardware and extended systems required for the intended device. In this scenario, developers and product designers needed to build physical lab environments using “target hardware” to create embedded systems and write their code.

The use of physical labs significantly slows down the embedded systems design process.

Testers needed the same setup to run tests and ensure reliability. Operations also needed access to the target hardware to put the device into the manufacturing workflow. Support engineers could only offer meaningful help to customers if they could replicate the customer environment on identical hardware, so they also needed their own lab. The cost of setting up separate labs is often cost-prohibitive. As a result, multiple teams must coordinate access to a shared lab - but only one can use the lab at a time. This is the current situation for many embedded system makers today. The results, depicted in Figure 1, show long development timelines and associated high levels of cost and risk.

Problems arising from the Status Quo

The status quo is expensive and slow, but it still currently works. However, it will become increasingly less viable as the industry moves to a faster, more complex product release cycle. The market expects sophisticated new embedded systems to come out on an accelerated schedule. Unfortunately, the traditional use of physical labs and target hardware/systems slow everything down.

Development delays

Developers must wait for target hardware to emerge from prototype manufacturing, which delays development efforts and hinders the ability to automate the development process. Testers also have to wait for target hardware/systems to run their test sequences, delaying the test cycle. The inevitable rushed testing schedules limit the extent and duration of testing, resulting in hindered quality and security.

All this hardware is costly and requires a capital expense (CapEx). In most embedded systems organisations, everyone struggles with the scarcity of target systems. People wait in line for access to equipment. Even with the best of intentions, new hardware takes time to go through “tape up” and prototyping. The setup and configuration time lengthen the time-to-market cycle, slowing down revenue growth and negatively affecting competitive strategy.

Preventing new DevOps methods

Support teams have to receive and then configure a lab featuring target hardware so they can mimic customer environments. The need to support embedded systems on multiple hardware platforms further compounds these already unscalable manual processes. For example, a device maker may want to create editions of a device that runs the Linux OS on an X86 chip, Windows on X86, and Linux on an ARM chip. This need requires dev, test and support teams to set up three separate sets of target system configurations. Maintaining hardware setups becomes more complex as the number of configurations grows.

Software development and the creation of new technology products are moving toward more agile, collaborative and automated methods in the form of DevOps, agile methodologies, and continuous development/continuous integration (CI/CD). However, using these approaches to building embedded systems is effectively impossible with the current practice of using target hardware. Cross-functional teams will struggle to work together if they cannot easily access identically configured hardware/system instances.

Without concurrent access to the exact same hardware and software setup, it’s impossible to implement agile development methods.

For example, without sharing tools, data, and assets, it’s quite challenging to debug a complex system. A tester may identify an issue, but it may hard to replicate. The result is a standoff. “It works on my end” is a common refrain in this scenario. It’s the customer who suffers, though, as the product goes to market with less quality assurance time than it required.

Tool limitations

Most currently available tools were intended for evaluating hardware or simple code, not for debugging complex embedded systems that include multiple combinations of devices. They work well in their intended environment but fall short when used to test or design complex embedded systems. The result is delayed time to market, higher development costs, and lost revenue and market share.

Hindered quality and security

Often, the lack of hardware prevents teams from performing enough test cycles and varied scenarios to maintain quality and security unless the product delivery cycle stretches to accommodate the necessary time. Plus, some security tests have the potential to cause damage to the equipment, necessitating waiting for replacement hardware to continue testing. Delays in new product introduction are unacceptable because late product availability results in lost revenue. Companies are torn between the need to introduce new products as planned vs the potential for customer problems. Since the customer problems are only “potential” and can be fixed later if they do occur, speed to market usually wins out.

Improve the Embedded Systems Design Process with Simulation

The embedded systems design process is held back by these traditional methods. If organisations want to remain competitive in the embedded systems market, they need simulation to streamline the entire process. Using simulation in a virtual lab eliminates the hardware and software roadblocks that create bottlenecks. It helps organisations get high-quality products to market faster while also improving internal collaboration and providing far-reaching business benefits.

Interested in learning more about why simulation is the solution to improving your embedded systems design processes? Download Wind River's complete eBook.

If you’re ready to get started with simulation, talk to one of the experts here. 

Courtesy of Wind River.