Introduction
Computing systems are everywhere. It’s probably no surprise that millions of computing systems are built ever y year destined for desktop computers (Personal Computers, or PC’s), workstations, mainframes and servers. What may be surprising is that billions of computing systems are built ever y year for a very different purpose: they are embedded within larger electronic devices, repeatedly carrying out a particular function, often going completely unrecognized by the device’s user. Creating a precise definition of such embedded computing systems, or simply embedded systems, is not an easy task. We might try the following definition: An embedded system is nearly any computing system other than a desktop, laptop, or mainframe computer. That definition isn’t perfect, but it may be as close as we’ll get. We can better understand such systems by examining common examples and common characteristics. Such examination will reveal major challenges facing designers of such systems.
Embedded systems are found in a variety of common electronic devices, such as: (a) consumer electronics – cell phones, pagers, digital cameras, camcorders, videocassette recorders, portable video games, calculators, and personal digital assistants; (b) home appliances – microwave ovens, answering machines, thermostat, home security, washing machines, and lighting systems; (c) office automation – fax machines, copiers, printers, and scanners; (d) business equipment – cash registers, curbside check-in, alarm systems, card readers, product scanners, and automated teller machines; (e) automobiles – transmission control, cruise control, fuel injection, anti-lock brakes, and active suspension.
Embedded systems have several common characteristics:
1) Single-functioned: An embedded system usually executes only one program, repeatedly. For example, a pager is always a pager. In contrast, a desktop system executes a variety of programs, like spreadsheets, word processors, and video games, with new programs added frequently.
2) Tightly constrained: All computing systems have constraints on design metrics, but those on embedded systems can be especially tight. A design metric is a measure of an implementation’s features, such as cost, size, performance, and power. Embedded systems often must cost just a few dollars, must be sized to fit on a single chip, must perform fast enough to process data in real-time, and must consume minimum power to extend battery life or prevent the necessity of a cooling fan.
3) Reactive and real-time: Many embedded systems must continually react to changes in the system’s environment, and must compute certain results in real time without delay. For example, a car's cruise controller continually monitors and reacts to speed and brake sensors. It must compute acceleration or decelerations amounts repeatedly within a limited time; a delayed computation result could result in a failure to maintain control of the car. In contrast, a desktop system typically focuses on computations, with relatively infrequent (from the computer’s perspective) reactions to input devices. In addition, a delay in those computations, while perhaps inconvenient to the computer user, typically does not result in a system failure.
This table compares the advantages and faults of different types of embedded systems
Embedded Systems Design
When approaching embedded systems architecture design from a systems engineering point of view, several models can be applied to describe the cycle of embedded system design. Most of these models are based upon one or some combination of the following development models:
- The big-bang model, in which there is essentially no planning or processes in place before and during the development of a system.
- The code-and-fix model, in which product requirements are defined but no formal processes are in place before the start of development.
- The waterfall model, in which there is a process for developing a system in steps, where results of one step flow into the next step.
- The spiral model, in which there is a process for developing a system in steps, and throughout the various steps, feedback is obtained and incorporated back into the process.
Why Is the Architecture of an Embedded System Important?
This thesis introduces an architectural systems engineering approach to embedded systems because it is one of the most powerful tools that can be used to understand an embedded systems design or to resolve challenges faced when designing a new system. The most common of these challenges include:
- defining and capturing the design of a system
- cost limitations
- determining a system’s integrity, such as reliability and safety
- working within the confines of available elemental functionality (i.e., processing power, memory, battery life, etc.)
- marketability and sell ability
- deterministic requirements
In short, an embedded systems architecture can be used to resolve these challenges early in a project. Without defining or knowing any of the internal implementation details, the architecture of an embedded device can be the first tool to be analyzed and used as a high-level blueprint defining the infrastructure of a design, possible design options, and design constraints. What makes the architectural approach so powerful is its ability to informally and quickly communicate a design to a variety of people with or without technical backgrounds, even acting as a foundation in planning the project or actually designing a device. Because it clearly outlines the requirements of the system, an architecture can act as a solid basis for analyzing and testing the quality of a device and its performance under various circumstances.
Furthermore, if understood, created, and leveraged correctly, an architecture can be used to accurately estimate and reduce costs through its demonstration of the risks involved in implementing the various elements, allowing for the mitigation of these risks. Finally, the various structures of an architecture can then be leveraged for designing future products with similar characteristics, thus allowing design knowledge to be reused, and leading to a decrease of future design and development costs.
By using the architectural approach in this thesis, I hope to relay to the reader that defining and understanding the architecture of an embedded system is an essential component of good system design. This is because, in addition to the benefits listed above:
1. Every embedded system has an architecture, whether it is or is not documented, because every embedded system is composed of interacting elements (whether hardware or software). An architecture by definition is a set of representations of those elements and their relationships. Rather than having a faulty and costly architecture forced on you by not taking the time to define an architecture before starting development, take control of the design by defining the architecture first.
2. Because an embedded architecture captures various views, which are representations of the system, it is a useful tool in understanding all of the major elements, why each component is there, and why the elements behave the way they do. None of the elements within an embedded system works in a vacuum. Every element within a device interacts with some other element in some fashion. Furthermore, externally visible characteristics of elements may differ given a different set of other elements to work with. Without understanding the «whys» behind an element’s provided functionality, performance, and so on, it would be difficult to determine how the system would behave under a variety of circumstances in the real world.
Even if the architectural structures are rough and informal, it is still better than nothing. As long as the architecture conveys in some way the critical components of a design and their relationships to each other, it can provide project members with key information about whether the device can meet its requirements, and how such a system can be constructed successfully.
Conclusion
Embedded systems are large in numbers, and those numbers are growing ever y year as more electronic devices gain a computational element. Embedded systems possess several common characteristics that differentiate them from desktop systems, and that pose several challenges to designers of such systems. The key challenge is to optimize design metrics, which is particularly difficult since those metrics compete with one another. One particularly difficult design metric to optimize is time-to-market, because embedded systems are growing in complexity at a tremendous rate, and the rate at which productivity improves ever y year is not keeping up with that growth.
Reference:
1. Embedded Systems Architecture. A Comprehensive Guide for Engineers and Programmers, by Tammy Noergaard, Elsevier 2012.
2. Embedded System Design — A UnifiedHardware/Software Introduction, Frank Vahid, Tony Givargis, 2002.
3. https://scribd.com
