4.3 Embedded Computer Systems
This book Section (and preview) is not a tutorial about embedded systems. Instead, it describes embedded systems in terms based on first principles and mental models (as for other topics in the rest of the book).
That emphasizes there is a ubiquitous unspoken assumption that embedded systems are physically and functionally small scale in respects such as computational (processor) capability, memory size, operating system, size/weight/power, etc., and are very cost-sensitive. That assumption is incorrect in general, instead being the most common special case of embedded systems. There can be, and there are, numerous embedded systems that are physically and functionally various scales–e.g., have multi-million dollar computers executing multi-million lines of software, and having large size, weight, and power consumption. Recognition of this fact has numerous ramifications on the R&D and business of developing and applying embedded systems.
The reason for discussing embedded systems in this book is the close relationship between real-time systems and embedded systems: most real-time computing systems are embedded systems; and many embedded systems are real-time computing systems. Although embedded real-time systems tend to be static ones, a minority are dynamic (as explained in Chapter 1) to a slight degree.
By “embedded system” people normally (and we here) are abbreviating “embedded digital computer system.” There have been, and still are, embedded systems that are all hardware (e.g., FPGAs, ASICs), analog electronic, mechanical, hydrolytic, or even biological; those are outside the scope of this book.
As earlier in this Chapter for “real-time system,” we accept for our purposes here the various intuitive understandings of the term “system.”
In this Section we address the meaning of “embedded system” by developing a mental model of it from first principles (as we have done in this book for terms such as “deadline,” “predictability,” “real-time,” “real-time system,” etc.).
To formulate a useful mental model of “embedded system,” we must focus on the need for one or more first principles for the term “embedded” in the context of “embedded system.” (We are not interested here in the term “embedded” as employed for other contexts such as media embedded on a web site, etc.).
The typical use of the term “embedded system” is not based on first principles for “embedded.” That can be observed by contrasting two significantly different meanings for “embedded system” and hence for “embedded:” the literal, and the figurative, meanings. These lead to different mental models and reifications of those models. Those differences have major impacts, including at the embedded system R&D and enterprise business levels.
The literal meaning of “embedded” is exactly what the word says: a computing system that is hidden (embedded) inside an application system. An embedded system is a “black box” that performs some dedicated functionality for the application system host. The users of the application system might be aware of the embedded system, but by default they have no direct visibility or control of it. As far as they know, the embedded computer’s functionality could theoretically be performed by relays or trained monkeys or even by magic. The users of the application system see and use the human interface provided for them by the application system. That interface may include a means for users or other entities to have local or remote communication with the embedded system (performing diagnostics, setting parameters, etc.).
This literal meaning is a first principle, P1, of embedded and embedded system.
Another first principle, P2, of embedded is that an embedded system’s dedicated functionality includes some combination of: observation of events and state in the application or its operational environment; application- and system-specific computation using some of that observed (and other) information; reaction on the application system or its operational environment, based on observations and computations. Very commonly, an embedded system’s functionality includes all three of these, performing some mix of closed loop and open loop reactive control of the application system and devices that are part of or exogenous to it. A simpler frequent case is that the embedded system primarily does computation using inputs received from the application system, and providing results back to the application system.
This first principle P2 implies that many application systems include some functionality and devices that are real-time in the sense described earlier in Chapter 4—i.e., to the degree that satisfaction of constraints on the timeliness and predictability of timeliness of actions is acceptable under the circumstances. In such cases, the embedded system has a number of actions, and interactions with the application system, that are necessarily also real-time ones to some appropriate degree. As explained in Chapter 2 for real-time actions and systems, the magnitudes of the time frames are not relevant to the definition of a real-time action or system. Other application systems with embedded systems have only non-real-time functionality with performance criteria such as maximal throughput, and thus almost inevitably have non-real-time embedded systems.
A major distinction between an embedded system and a non-embedded one follows directly from the two first principles of “embedded,” P1 and P2. The developers of embedded systems hardware and software usually need a great deal of understanding about the application system functionality and design, and of the devices therein that it is interacting with. Indeed, often the embedded system hardware and software must be co-designed at a low level of detail (ordinarily the application system’s hardware and software are a given), calling for some education and experience of computer engineering as well as of some computer science aspects. This factor alone makes embedded system hardware and especially software more difficult than for non-embedded computers—e.g., desktop, laptop, server ones.
The figurative meaning of “embedded system” is a special case of (but not implied by) the first principle P1 literal meaning. It is based on a different mental model that adds numerous explicit and even implicit assumptions about the embedded system, and about the application system, and about the application system’s execution environment. Most notably, the use of the term “embedded system” almost always incorrectly assumes that the embedded system is extremely cost sensitive, due to production volume or low cost of the application system, and severely resource-constrained—small scale in hardware size/weight/power, and in embedded system software size. Those assumptions are often correct, and everyone can immediately think of many examples. But they are not correct in general, contrary to popular belief. Extremely cost-sensitive resource-constrained embedded systems range in software difficulty from trivial to tricky.
The figurative meaning of “embedded system” overlooks the fact that they may be, and are, not just only small scale, but of various scales in capabilities and size/weight/power consumption. There are embedded systems having multi-million dollar computers–including multiprocessors, multi-computers, distributed computers—executing multi-million lines of software, and having large size, weight, and power consumption.
Larger scale embedded systems are found in application systems of various scales, including very large complex ones. Such application systems almost always include multiple embedded systems of different scales. Most embedded system developers have not been exposed to this class of very large complex real-time embedded systems and application systems.
An example class of large scale real-time embedded systems in large scale real-time application systems is military C4ISR—command, control, communications, computers, intelligence, surveillance, and reconnaissance. Computationally intensive parts include controllers for the different modes of multi-mode multi-function AESA radars, signal processing for target identification, surveillance algorithms for target tracking, battle management/command and control. Another example class is systems for defense against cruise missiles and ballistic missiles.
Next: TUF/UA History