Programming Techniques for Reliable Embedded Systems

Module code: EG7510

From bare metal, to complex, reliable, safety-critical, and certified embedded systems.
 
Embedded systems are ubiquitous. Our day begins with an alarm clock that is most probably running on a microcontroller in a mobile phone. We travel in cars and trains and aeroplanes – all of which are increasingly controlled by software that enhances the safety and comfort of our experiences. We rely on the security of electronic banking systems worldwide to protect and manage our assets. We have massively complex communications systems involving satellites, phones, tablets, e-mail, video conferencing and much more. The growth in the pervasive nature and reliance of microelectronic software systems on all aspects of our lives over the past 30 years is unprecedented – and the demands that we place on them are rapidly and vastly outstripping our ability to reason about them.

Programming embedded systems throws up many challenges – both to the experienced software engineer and to the new embedded systems architect. For instance, a deeply embedded system usually performs a very limited and specific function as part of a larger, complex environment. Unlike a desktop computer or tablet, it may well have a very limited interface for monitoring and debugging. It may also have significant resource constraints due to power, cost or physical space requirements. All of these have to be taken into consideration when designing software for these systems.

The term 'reliable' covers a multitude of possibilities. It may mean safety-critical – for instance, the flight control system of an aircraft – where life is at stake. It may mean robust – where a system should be dependable in the presence of known faults or failures such as a traffic management system or backup safety system in a power plant. It may even mean consumer friendly – where a product provides a service to a consumer and the product offers some commercial advantage in terms of the service, or even a product which can offer reduced warranty costs.

In this module, you will study state-of-the-art techniques for programming modern microcontroller based systems. We will look at the C programming language, and the components of this language that are specifically used for microcontroller programming using state-of-the-art industrial tools and hardware platforms. We will consider what a software architecture is – and how different software architectures have an impact both on the reliability of a system, and on our ability to make arguments about the reliability of a system. You will study this in the context of modern hardware platforms, and the different types of facilities that modern hardware offers to support reliability at both the system level and the software level. We will then analyse this in the context of both modern programming guidelines and standards, and in the types of requirements commonly seen in certification and validation processes.

• This module is also available as a stand-alone, five-day CPD course.

Topics covered

Introduction to reliable embedded systems

• What is an embedded system, what is reliability, and why do we care about it? 
• How can we program these systems, and why does the world keep using the C language? 
• Can we make the C language safer to use?

Key software architectures

• What exactly does 'software architecture' mean? 
• How does it affect a system and what we can do with a system? 
• Do different software architectures have inherently different properties? 
• What do those properties look like and what effect do they have?

Exploring modern hardware platforms

• What is a microcontroller, and what makes it different to a microprocessor? 
• What is reconfigurable hardware?
• Can we exploit modern hardware to improve the inherent reliability of our systems? 
• Is it important to have the biggest and best hardware available, or can we consider system specific requirements?

Working with multiple tasks and distributed systems

• Although our embedded system may perform one dedicated role as part of a larger system, how can we decompose the job that it does into components that are manageable, specific, and possibly even atomic? 
• How does this impact on reliability when these components may be physically, or even geographically, distributed?