This is not normally a consideration in embedded system, where different sub-systems all contribute to the overall system mission. There are, however, classes of Embedded System 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 System is "horses for courses." Modern embedded devices frequently contain massive amounts of software, measuring in the millions of lines of code (LoC). This implies a need for high developer productivity, which creates the demand for operating 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 numerous incredibly different OSes on the same system. This is accomplished by running each OS over 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 just one processor core, which frequently results in lower BoM cost. But it really is actually useful even over a multicore setup since the hypervisor partitions the shared physical memory between OSes without a need for further hardware mechanisms. What is particularly appealing would be the abstraction with the underlying architecture provided by the hypervisor. The system designer can develop the program stack independent with the number of cores and can use the hypervisor to map the same stack to uni- or multi-processor hardware.
While good for user-facing application, these rich OSes do not provide an appropriate base for other Embedded System application, in particular real-time subsystems. These are each functionality and legacy problems. Rich OSes do not tend to have the low and highly predictable interrupt latencies required by embedded system, and frequently many real-time subsystems are large and difficult to port to APIs provided by rich OSes.
No comments:
Post a Comment