This is not normally a consideration in embedded system, where different sub-systems all contribute to the overall system mission. You will find, however, classes of Embedded Systems that are much more like enterprise-style servers, such as high-end network infrastructure devices. This kind of systems might indeed be served adequately by an enterprise-style hypervisor. This class of system, however, will be ignored in the remainder of this article.
The typical reason for using multiple OSes in an Embedded Systems is "horses for courses." Modern embedded devices frequently contain massive amounts of computer software, measuring in the millions of lines of code (LoC)..! This implies a need for high developer productivity, which creates the demand for working systems with familiar and high-level APIs, Consequently, "rich OSes," such as Linux or Windows, are becoming development platforms of choice in the embedded space.
The inevitable consequence is a requirement for co-existence of many incredibly different OSes on the same system. This is accomplished by running each OS on a separate processor. However, in order to properly isolate the two systems from each other, physical memory needs to be partitioned either by connecting the processors to different memory banks or by having some other mechanism for partitioning shared physical memory.
Virtualization allows this to be done on a single processor core, which frequently results in lower BoM cost. But it truly is actually valuable even on a multicore setup since the hypervisor partitions the shared physical memory between OSes without a need for further computer hardware mechanisms. What is particularly appealing is the abstraction with the underlying architecture provided by the hypervisor. The system designer can develop the software package stack independent from the number of cores and may use the hypervisor to map the same stack to uni- or multi-processor equipment.
While good for user-facing software, these rich OSes do not provide an appropriate base for other Embedded Systems computer software, in particular real-time subsystems. These are each functionality and legacy problems. Rich OSes do not tend to have the very low and highly predictable interrupt latencies required by embedded system, and frequently several real-time subsystems are large and difficult to port to APIs provided by rich OSes.
No comments:
Post a Comment