MENU

Managing the complexity of embedded software development through design automation tools

Managing the complexity of embedded software development through design automation tools

Technology News |
By Julien Happich



For those in the industry this won’t come as a surprise. Embedded systems empower every aspect of modern life. Within those systems there are now hundreds of millions of lines of code, each of which has been optimised for a specific hardware platform and debugged to ensure reliability, security and safety. Developing embedded software is rapidly becoming the single largest risk and cost in product development, so choosing the right tools for the job is now fundamental to success.

 

The Software Development Paradigm

Embedded software programming was once a matter of manually transposing an intention expressed using mnemonics into machine code (normally represented using hexadecimal or binary values) and putting those values into a persistent storage device, readable by a microprocessor. Things have changes a lot in the last 40 years or so.

The third generation of programming languages saw high-level, platform-independent languages emerge and, with them, productivity increase. With abstraction came the ability to manage complexity which, as a result, has increased in line with processing performance. The two have provided mutual motivation ever since.

Today, developing embedded software is still platform-dependent but the balance of that dependence is changing. Increasingly higher levels of abstraction mean code is more transportable but is still reliant on the underlying hardware features. Uniquely in the embedded domain, the intrinsic link between hardware and software remains as important today as it ever has, but overall system functionality now relies more heavily on the software.

This makes software development the single most important or, at least, influential element of product development. Without embedded software, no end product would function, and without the ability to develop embedded software efficiently and reliably the overall cost of product development would become untenable, threatening innovation and progress.

 

The System-Level View

Software can broadly be categorised as high-level or low-level; high-level can be written to execute on a system (such as PC or Server) after the system has been fully developed, while low-level software is written to create the system. Embedded software is where the operating system, middleware (such as communication protocols and drivers) and the application code come together to interact directly with the underlying hardware (see the next section for more details), while high-level software is more dependent on the operating system and can be largely hardware-agnostic.

Developing a system architecture requires an appreciation of these two domains and how they must inevitably interact. It also requires an understanding of how software in the two domains is developed.

A relatively new trend within high-level software development involves fast and frequent iterations. This so-called Agile approach to software development is intended to accelerate development by quickly evolving a software platform against requirements that can also change or evolve in parallel with development.


Where Hardware meets Software

One of the unique things about embedded software is the level to which it is able to interact with the hardware platform. Despite considerable efforts to consolidate embedded systems around a common architecture, the industry remains fragmented, meaning systems are invariably bespoke. Microcontrollers based on the ARM Cortex-M family of cores are numerous, with most semiconductor manufacturers holding IP licenses for at least one of the cores. However, despite this proliferation there are still many alternative architectures available. Even ARM-based devices from different manufacturers feature numerous variations.

This means that not only is it possible for embedded software to interact with the underlying hardware, it is a fundamental feature of embedded systems. The interaction between hardware and software in embedded systems is normally referred to as firmware, because of the way the two influence each other and the overall system behaviour.

The fragmented nature of the embedded industry means developing firmware is an iterative process but one that is much less agile than higher-level software. A major part of that process is verification and, inevitably, debugging.

 

Software-as-a-Service

As the cost of software development increases it threatens to become a real barrier to entry. To address this, some manufacturers are now adopting a Software-as-a-Service approach to development tools. There is an increasing number of development tools that can now be accessed over the internet. This approach isn’t new; the first computer networks pioneered the concept of centralised processing accessed using ‘dumb’ terminals — the thin client is today’s equivalent.

 

Tool Selection Criteria

Managing complexity is a fundamental feature of Engineering Design Automation (EDA) tools; tools that allow features and functions to be described at a high level and then automatically translated into a low-level, deployable design. A major part of system-level design is now focused not on the hardware but the software development process, so tools that can help automate and manage that process are increasingly useful.

For some systems, simple tools are still best. This may mean that a word processor or spreadsheet application is all a Project Manager may need. For more complex systems, there are now tools available to meet these demands.

Many of these tools are intended to manage the entire development process, from requirements to production; Product Lifecycle Management, or PLM tools, as they are known.

Specific technologies have evolved to support this, such as the Unified Modelling Language (UML), a vendor-driven standard managed by the Object Management Group (www.omg.org) which allows software to be modelled before any code is written, to evaluate the perceived needs and expectations against actual results.

Entity Relationship Diagrams (ERD) are a method for showing, graphically, the relationship between entities and are often used in the development of databases. Tools that integrate these technologies now targeting electronic product development include Visual Paradigm and Enterprise Architect; both are visual modelling tools and make use of UML. Some UML tools are now also capable of generating software from high-level requirements captured in this way.


Operating Systems

Processors targeting embedded applications are now much more powerful than they were even five years ago. They range from 8- to 64-bit architectures and while 8-bit devices are still used in some ‘simple’ applications, it is increasingly common (and cost-effective) for 32-bit or even 64-bit devices to be specified in embedded designs.

One of the benefits of more capable processors is their ability to run an operating system. Many operating systems focused on embedded systems are real-time and highly optimised, but still offer the opportunity for customisation. Non real-time operating system may be used when the application is not so deeply embedded and often the operating systems chosen are Windows Embedded Compact (or Windows CE) or Linux.

Both of these operating systems are configurable; Microsoft’s Platform Builder is an Integrated Development Environment (IDE) for customising Windows CE, while the popular Linux distribution, Yocto, is supported by an Application Development Toolkit that provides the same functionality. In this context, Yocto could, to some extent, be considered to be a fully featured operating system that requires some high level configuration at implementation and while ‘hardware agnostic’ is readily portable to a range of processors able to run a Linux distribution. To further support this configurability and portability, Buildroot is an open-source project for building embedded Linux systems using a cross-compilation toolchain that can target a specific embedded processor. While the latter comes with less features, it has the advantage of a faster ramp-up phase.

 

Embedded Software

As described earlier, firmware really only exists as the point where dedicated hardware and software come together, to create an embedded system. It is widely accepted that firmware complexity is on an upward trend, as increasing levels of performance available from advanced integrated devices are exploited by more compute-intensive software.

Managing the complexity of firmware, while meeting system requirements, is achieved through choosing the right development tools for writing and debugging firmware. Integrated Development Environments (IDEs) were developed for this purpose, as they provide a single platform from where most or all of the tasks for firmware development can be carried out. As such they are measured by their capabilities and how well they support productivity.

Despite a growing number of independently developed IDEs, many integrated device manufacturers still see the value in offering their own; one of the main benefits of this approach is it affords a closer integration between software and hardware. As complexity increases, so too must the capabilities of the IDE and many are now supported by eco-systems, or form part of a larger framework from which to start application development. The more extensive the framework, the less development is needed, at least that’s the intention.

Figure 1 – example of an IDE used for development

A prime example of this is the Synergy Platform from Renesas. It brings together a Real-Time Operating System (RTOS), middleware and communication stacks. It provides the ability to access the main features of the underlying hardware through software-based APIs. In a similar way, STMicroelectronics also offers a platform approach to software development in the form of its STMCube initiative, which also extends the concept of a basic IDE to raise the abstraction layer of software development, while providing device/family-specific middleware to ease the software development burden. This software-centric approach to embedded system development from device manufacturers such as Renesas, STMicro and others is aimed at accelerating the design process.

Independent development tool providers tend to focus more on the firmware in general and debugging in particular. While the debugging process is iterative and closely dependent on the underlying hardware, it is often entirely software-centric; assuming that the hardware design is finalised, any bugs that are found will invariably be addressed and fixed in software. The reason for this is because it is simpler and/or more cost effective to make changes at the software level rather than change the hardware. In reality, there will inevitably be hardware issues revealed during the debug process, but wherever possible they will be referred for modification in a later iteration of the hardware.

As they are hardware-agnostic, IDEs and debuggers from independent tool providers will often be able to support a number of microcontroller families from competing manufacturers and, in the case of Lauterbach’s Trace32 family of modular development/debug tools, support a wide number of RTOS providers, also.

The Trace32 system provides industry-leading features for debug and trace, including RTOS debug at the kernel level. In addition to this, it also supports hardware extensions for logic analysis, protocol analysis, in-circuit emulation, timing analysis and stimulus generation. Device programming is also supported.

A major feature of debug tools is the ability to set breakpoints; halting execution at the hardware level based on events detected or placed in the software. This is a powerful feature of the Trace32 in-circuit debugger and is often employed alongside tracing; recording the execution of the software instruction by instruction in order to trace events and find bugs.


An example of how these features can be combined to create a powerful development system comes in the form of Lauterbach’s μTrace for Cortex-M — an all-in-one debug and trace module targeting microcontrollers based on the ARM Cortex-M cores. This debug and trace solution can interface to over 1000 Cortex-M based MCUs and support both high-level (C/C++ source) and low level (assembler) code debugging.

With many advanced features, including simple and complex breakpoints, OS-aware debugging and support for multicore debugging, it can also be used for in-system programming. Trace features include code coverage and task/function runtime analysis, and the ability to measure the energy used by the target during runtime.

The μTrace for Cortex-M is just one of Lauterbach’s embedded development tools and is complemented by software-only debuggers, in-circuit emulators and logic/protocol analysers.

With most of a system’s complexity residing at the firmware level, it is essential to choose the most productive tools and understand fully the features they offer.

Figure 2 – Screen capture from QtCreator.

Application Development

In the Internet of Things era even deeply embedded devices are connected and will likely offer services that can be shared with other devices or even people.

The main form of accessing these services, wherever they may be, is through Applications; they now form the User Interface in many instances, exploiting the hardware platforms we carry with us, such as Smart Phones or Tablets, as well as PCs and, increasingly, Smart TVs. Developing an application that can execute on all these platforms is rapidly becoming the domain of cross-platform solutions.

A cross-platform solution allows a single application to target a range of hardware/software platforms, irrespective of the processor or operating system present. This usually lowers the cost of developing and maintaining an application.

 

Cloud-based Development

Cloud developments are involving tools that are no more specific to embedded systems but come from the standard IT development. You’ll find here all the tools for developing and testing PHP, C#.NET, JAVA or similar, which usually brings tools like Visual Studio, Eclipse or IntelliJ. We can also highlight some advanced text editor like SublimeText or Atom

While those tools are not that much specific to the IoT types of scenario, the way they are being used especially in the debugging and instrumentation phase might differ a little from what is usually being perceived in standard cloud processing applications and in particular due to the need of specific environment with object, databroker or any kind of device connectivity.

Besides, what we see emerging right now are tools that allows setting up and configure an IT infrastructure, which can be either SAAS or PAAS oriented. Indeed, Cloud service providers like Microsoft for instance make those tools (Visual Studio and WebMatrix) available in order to deploy cloud solution but also smoothen the connectivity of embedded system to Cloud systems for companies with limited knowledge, experience or resources on the IT side.

 

Quality Control

Quality is often subjective and difficult to define because it can be difficult to quantify. With software, however, there are very quantifiable methods of measuring quality and first among them is coding standards.

Many industries now rely on coding standards such as MISRA for assessing software quality and the task of comparing source code against coding standards falls to static analysis tools. These tools, such as QA·C or Coverity from Synopsys, are widely adopted in safety-critical sectors such as aerospace and automotive, but are increasingly used in the Industrial sector, as well as some light industrial and consumer applications.

Static analysis returns errors and warnings when source code fails to comply with coding standards, and while it doesn’t guarantee the software meets the requirements (or is bug-free) it does indicate how well the code has been written, and that can often help minimise or expedite the debug process.


Revision Control

Revision control systems are commonly used in the enterprise domain, where branching and merging are perhaps more common. However, within the embedded domain, version control is just as relevant.

It is more common for embedded devices to experience hardware revisions throughout the product lifecycle, resulting in software revisions to support the new or updated hardware. Keeping track of firmware builds is the job of a revision control system. This may be as simple as a word processor or spreadsheet document, or a general purpose database.

Perhaps the most well know of the dedicated tools, at least in the open source space, is Apache Subversion; a mostly compatible successor to Concurrent Versions System.

Arguably the most widely used distributed versioning system is GIT, originally developed by Linus Torvalds to support the Linux kernel, while GitHub is the popular web-based version.

 

Conclusion

Embedded software now drives product development. It constitutes the largest part of a design budget both in terms of time and capital expenditure. The fragmented nature of embedded design means that open source software and software reuse remain only part of the solution.

Bringing any electronic product to market now encompasses all aspects of software development, from very low level code running on a deeply embedded processor to databases hosted in the cloud, and everything in between. It is becoming difficult for any OEM to have that amount of expertise in-house.

EDA tools are emerging that aim to expedite the embedded software development process; knowing which tools to invest in (in terms of both time and money) is becoming an increasingly complex process and one that necessarily needs to be repeated for every new product development process.

Specialists in embedded software development, such as Witekio, are now in a position to provide that level of expertise, at whatever level an OEM needs it; from developing a driver for an embedded microcontroller to creating a web-based interface to a connected factory or selecting the right EDA tools.

The IoT is developing rapidly and not being a part of it is really no longer an option for long term sustained success. Choosing the right partner for your next project will help guarantee that success.

 

About the author:

Anthony Pellerin is Director of Technology at Witekio – www.witekio.com  

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s