Search for: All records

Cyber-physical systems (CPS) increasingly require real-time, high bandwidth data communication and processing. To address this, Time Sensitive Networking (TSN) provides latency-bounded data trans- mission at one or more gigabits-per-second throughput. However, it does not commonly connect directly to I/O devices, such as sensors and ac- tuators. In contrast, Universal Serial Bus (USB) is ubiquitous for device I/O, but has yet to be widely adopted for host-to-host networking. This paper considers the use of a common USB software stack for both device I/O and host-to-host communication. We compare against a sys- tem using USB for device I/O and TSN for host-level networking. Our findings show that a unified approach using USB results in reduced soft- ware complexity, simplified bus coordination, and more effective miti- gation of priority inversion when transferring data across multiple bus segments. Experiments show that end-to-end latency is within expected delay bounds, and is reduced if the same USB software stack is used for all communication with a given host. This suggests that bridging chal- lenges exist in current systems, which are solved by either extending a high-bandwidth bus such as TSN to support device I/O, or enhancing USB with improved networking capabilities. 

Cyber-physical systems (CPS) increasingly require real-time, high bandwidth data communication and processing. To address this, Time Sensitive Networking (TSN) provides latency-bounded data transmission at one or more gigabits-per-second throughput. However, it does not commonly connect directly to I/O devices, such as sensors and actuators. In contrast, Universal Serial Bus (USB) is ubiquitous for device I/O, but has yet to be widely adopted for host-to-host networking. This paper considers the use of a common USB software stack for both device I/O and host-to-host communication. We compare against a system using USB for device I/O and TSN for host-level networking. Our findings show that a unified approach using USB results in reduced software complexity, simplified bus coordination, and more effective mitigation of priority inversion when transferring data across multiple bus segments. Experiments show that end-to-end latency is within expected delay bounds, and is reduced if the same USB software stack is used for all communication with a given host. This suggests that bridging challenges exist in current systems, which are solved by either extending a high-bandwidth bus such as TSN to support device I/O, or enhancing USB with improved networking capabilities. 

Multicore PC-class embedded systems present an opportunity to consolidate separate microcontrollers as software-defined functions. For instance, an automotive system with more than 100 electronic control units (ECUs) could be replaced with one or, at most, several multicore PCs running software tasks for chassis, body, powertrain, infotainment, and advanced driver assistance system (ADAS) services. However, a key challenge is how to handle real-time device input and output (I/O) and host-level networking as part of sensor data processing and control. A traditional microcontroller would commonly feature one or more Controller Area Network (CAN) buses for real-time I/O. CAN buses are usually absent in PCs, which instead feature higher bandwidth Universal Serial Bus (USB) interfaces. This article shows how to achieve real-time device I/O and host-to-host communication over USB, using suitably written device drivers and a time-aware POSIX-like “tuned pipe” abstraction. This allows developers to establish task pipelines spanning one or more hosts, with end-to-end latency and throughput guarantees for sensor data processing, control, and actuation. 

This paper presents ModelMap, a model-based multi-domain application development framework for DriveOS, our in-house centralized vehicle management software system. DriveOS runs on multicore x86 machines and uses hardware virtualization to host isolated RTOS and Linux guest OS sandboxes. In this work, we design Simulink interfaces for model-based vehicle control function development across multiple sandboxed domains in DriveOS. ModelMap provides abstractions to: (1) automatically generate periodic tasks bound to threads in different OS domains, (2) establish cross-domain synchronous and asynchronous communication interfaces, and (3) handle USB-based CAN I/O in Simulink. We introduce the concept of a nested binary, for the deployment of ELF binary executable code in different sandboxed domains. We demonstrate ModelMap using a combination of synthetic benchmarks, and experiments with Simulink models of a CAN Gateway and HVAC service running on an electric car. ModelMap eases the development of applications, which are shown to achieve industry-target performance using a multicore hardware platform in DriveOS. 

Complex embedded systems are now supporting the co-existence of multiple OSes to manage services once assigned to separate embedded microcontrollers. Automotive systems, for example, now use multiple OSes to consolidate electronic control unit (ECU) functions on a centralized embedded computing platform. Such platforms have the complexity of an industrial embedded PC, with multiple cores and hardware virtualization capabilities. This enables a partitioning hypervisor to spatially and temporally share the physical machine with separate guest OSes, which manage services of different criticality levels. However, PC-class hardware incurs a large latency to bootstrap an OS and associated application-level services. A firmware BIOS performs a power-on-self-test, and then loads OS images into memory from a bootable storage device. This latency is unacceptable in time-critical embedded systems, where important services must be operational within milliseconds of starting the system. In this paper, we present Jumpstart, a PC-class power management approach that minimizes the wakeup delay of a partitioning hypervisor for use in embedded systems. We show how Jumpstart resumes critical OS services and tasks from a low power suspended state in approximately 600 milliseconds, and reduces full system startup delay by a factor of 23. Additionally, Jumpstart consumes minimal power compared to approaches requiring a system boot from a previously powered-off state. By comparison, an alternative firmware-optimized bootloader, called Slim, reduces boot latency by a factor of 1.8. 

Autonomous multicopters often feature federated architectures, which incur relatively high communication costs between separate hardware components. These costs limit the ability to react quickly to new mission objectives. Additionally, federated architectures are not easily upgraded without introducing new hardware that impacts size, weight, power and cost (SWaP-C) constraints. In turn, such constraints restrict the use of redundant hardware to handle faults. In response to these challenges, we propose FlyOS, an Integrated Modular Avionics (IMA) approach to consolidate mixed-criticality flight functions in software on heterogeneous multicore aerial platforms. FlyOS is based on a separation kernel that statically partitions resources among virtualized sandboxed OSes. We present a dual-sandbox prototype configuration, where timing-and safety-critical flight control tasks execute in a real-time OS alongside mission-critical vision-based navigation tasks in a Linux sandbox. Low latency shared memory communication allows flight commands and data to be relayed in real-time between sandboxes. A hypervisor-based fault-tolerance mechanism is also deployed to ensure failover flight control in case of critical function or timing failures. We validate FlyOS’s performance and showcase its benefits when compared against traditional architectures in terms of predictable, extensible and efficient flight control.