Friday, June 9, 2017

Microkernel

Introduction

A microkernel provides only mechanisms: virtual memory management,  thread management, inter-process communications(IPC) and optionally scheduling that are needed to implement an operating system(OS), while OS functionalities, like devices driver, file system,  interrupts and network stack are implemented as services in user space.

Why Microkernel

  • Reliability: A major source of linux panic is device driver because it makes a large part of Linux kernel source and some are not written very carefully. By running it as services in user space, devices driver in false situation can be restarted without restarting the complete OS which is very helpful for high availability use cases.
  • Security: With services running in user space, access to privileged resources is restricted. Some also argued that minimality principle of microkernel is a direct consequence of principle of least privilege.
  • Realtime performance: With microkernel, kernel operations are few and short duration, keep use of locks at minimal level and lower scheduling latency. 
  • Debuggability: Since all services are running in user land, debugging a service is the same as debugging an application. 

Challenge of Microkernel

  • IPC: In monolithic systems, service is obtained with a system call which requires two kernel/user mode switches. In mircokernel systems, this requires four context switches plus overhead of user data copying.
  • Performance: Since all services, e.g. page fault handling, interrupt handling etc. are implemented as user space program, means of communications between server and client as well as context switch and scheduling latency are essential for microkernel system design.

Implementations

L4 Microkernel Family

L4 is a family of second generation microkernels including L4 kernel interface after its predecessor L3, which was developed by Jochen Liedtke as a response to poor performance of earlier microkernel-based operating systems.

L4 was written in assembly language. To prove that high performance could also be achieved with high level programming language, Liedtke started L4Ka::Hazelnut, a c++ version that supports IA-32 and ARM architectures.  L4Ka::Pistachio is a platform-independent implementation with new L4 API release.

L4/Fiasco is another c++ version implemented independently by TUD:OS of TU Dresden. It is fully preemptiable and used as a basis of hard real-time operating system. Its successor, Fiasco.OC is a third generation microkernel, characterised by a security-oriented API with resource access controlled by capabilities, virtualization as a first-class concern, novel approaches to kernel resource management[1].  NOVA is a virtualization environment running on x86 multi-core systems.

L4/MIPS and L4/Alpha are 64-bit implementations, developed by University of New South Wales(UNSW).  Later UNSW forked L4Ka::Pistachio into new version of NICTA::L4-embedded. OKL4 is a spinoff version from NICTA with focus on commercial use. OK Labs also owns seL4, a high assurance version which has achieved complete formal verification and thus gone beyond CC EAL 7. 

Figure 1: L4 family tree, from Wikipedia.

QNX Neutrino RTOS

This sections, however, will try to dig into implementation details. QNX Neutrino RTOS features open standards POSIX and messaged-based IPC.

POSIX threads and processes

A process contains one or more threads, which is the minimum unit of execution.  The threads share process's MMU-protected address space. Threads are scheduled globally and there are 256 ready queues, one for each priority. QNX Neutrino RTOS supports following scheduling algorithms[3]:

  • FIFO scheduling
  • round-robin scheduling
  • sporadic scheduling
It provides following primitives for synchronizing threads:
  • Mutexes
  • Condvars
  • Barriers
  • Sleepon locks
  • Reader/writer locks
  • Semaphores
  • FIFO scheduling
  • Send/Receive/Reply
  • Atomic operations
Synchronization can also be done by scheduling policies, message passing and atomic operations.

IPC

Message-passing

Message passing is synchronous which means that a thread that sends message with MsgSend will be blocked until the receiving thread does MsgReceive, processes the message and replies it. The message-passing primitive also supports multipart transfers which mean that the message itself doesn't have to in single, continuous buffer. Before passing a message, a sending thread needs to first make a connection attaching to a channel that is made available by a receiving thread. Message-passing is the primary form of IPC. Other forms of IPC are mostly based on Message-passing.
Figure 2: Client(top)/Server(bottom) states change in a send-receive-reply transaction[3]

Pulses

Pulse is a non-blocking notification mechanism that often used within interrupt handlers. A pulse carries a small, fixed size payload.

Mach Family

Mach is one of the earliest implementations of microkernels, developed by Carnegie Mellon University(CMU). Its derivatives are the basis of modern operating system kernels, e.g. GNU Hurd, iOS, MacOS etc. Mach was started as monolithic kernel on the base of BSD 4.2 kernel with an effort to produce a kernel with a short list of generic concepts: task, thread, port and message. A public release 1 was made in 1987 and release 2 next year.  A "true" microkernel Mach 3 was released in 1990 after moving UNIX layer out of the kernel into user space.

GNU Hurd consists of a set of protocols and services that runs on top of CMU's Mach 3. In 1994, Mach development was stopped at CMU.  GNU Hurd switched to Utah's Mach 4. Once the Mach 4 was discontinued, GNU Hurd's Mach was known as GNU Mach. There were also other efforts of porting GNU Hurd to other microkernels, e.g. L4, Coyotos. There are 24 services included in GNU Hurd[2].

XNU, stands for "X is Not Unix", is a modified "hybrid" Mach 3 kernel, with file system, network, process and memory management implemented in kernel space. XNU is the kernel for Apple's iOS, tvOS, watchOS and macOS. 

References

[1] Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). "Kernel design for isolation and assurance of physical memory". 1st Workshop on Isolation and Integration in Embedded Systems. Glasgow, UK.
[2] "Preliminary GNU/Hurd User Interface Description". Debian. 2016-07-05. Retrieved 2017-06-10
[3] "QNX Neutrino RTOS System Architecture". (2014, Feb. 20). QNX Software Systems Limited.  Retrieved 2017-06-07, from http://support7.qnx.com/download/download/26183/QNX_Neutrino_RTOS_System_Architecture.pdf

Wednesday, June 7, 2017

QNX Automotive

Hypervisor

Development cycle for smart phones is usually measured as months while it is years for vehicles. One reason is the safety nature of vehicles. To shorten development time and thus reduce coast, safety-critical components are separated from less critical ones.  QNX hypervisor enables separation and isolation of components of different safety levels by placing them in different guest operating systems.  One extra benefit of this separation is easier to make a minimal Trusted Computing Base(TCB) and thus to obtain and maintain safety certifications, e.g. ISO 26262, IEC 61508, and IEC 62304.  QNX hypervisor is an extended implementation of QNX Neutrino RTOS.

QNX hypervisor has following features[1]:

  • Type 1 Hypervisor
  • Safety certification pedigree
  • Virtual CPU model
  • Pin to cores or share cores based on priority
  • Adaptive partitioning - Allows for CPU guarantees of guest runtime
  • 64-bit and 32-bit guests: QNX, Linux, Android, RTOS
  • Shared memory with triggering
  • VirtIO (0.95/1.0) device sharing
  • TAP and peer-to-peer networking with bridging
  • Failure detection and restart of guests
  • Virtual watchdog for guest integrity checking
  • Low overhead (typical < 2%)
  • Graphical tools for analysis and debug
QNX Hypervisor, Copyright QNX Software Systems Limited


QNX Neutrino RTOS

QNX Neutrino is a micro-kernel real-time OS that features Open Systems standard POSIX API, wide scalability, advanced security mechanisms and high reliability.  It has been time-tested and field-proven for mission-critical applications in industry like nuclear plants, military and medical equipments.

Real-time serving is a must requirement for automotive operating systems. ADAS or even instrument cluster requires deterministic response time.  POSIX realtime extensions defines a set of realtime extensions to the base 1003.1 standard. These extensions consist of semaphores, prioritized process scheduling, realtime extensions to signals, high-resolution timer control, enhanced IPC primitives, synchronous and asynchronous I/O, and a recommendation for realtime contiguous file support[2]. 

A micro kernel implements minimal amount of software that provides the mechanism to implement an operating system.  This minimal design has been further formalized by Liedtke in his minimality principle:
A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality.[3]
QNX, however, has a different definition - A microkernel OS is structured as a tiny kernel that provides the minimal services used by a team of optional cooperating processes, which in turn
provide the higher-level OS functionality[2]. Thus as compared with L4 microkernel family, QNX's micro kernel is slightly bigger with addition of following fundamental services[2]:

  • thread services via POSIX thread-creation primitives
  • signal services via POSIX signal primitives
  • message-passing services—the microkernel handles the routing of all messages between all threads throughout the entire system.
  • synchronization services via POSIX thread-synchronization primitives.
  • scheduling services—the microkernel schedules threads for execution using the various POSIX realtime scheduling policies.
  • timer services—the microkernel provides the rich set of POSIX timer services.
  •  process management services—the microkernel and the process manager together form a unit (called procnto). The process manager portion is responsible for managing processes, memory, and the pathname space.
QNX Neutrino RTOS, Copyright QNX Software Systems Limited

QNX Car Platform

QNX car platform is an aggregation of multiple QNX technologies - Neutrino RTOS, mobile connectivity framework, acoustics middle ware, multimedia engine, and an application framework that supports Qt and HTML 5. Android apps can run natively on QNX or on guest android system. The wide support of application frameworks make it easier to port apps from consumer electronics space.
QNX Car platform, Copyright QNX Software Systems Limited

References

[1] QNX Hypervisor. In qnx.com. Retrieved 2017-06-07, from http://www.qnx.com/content/qnx/en/products/hypervisor/index.html
[2] QNX Neutrino RTOS System Architecture. (2014, Feb. 20). QNX Software Systems Limited.  Retrieved 2017-06-07, from http://support7.qnx.com/download/download/26183/QNX_Neutrino_RTOS_System_Architecture.pdf
[3] Liedtke, Jochen (December 1995). "On ยต-Kernel Construction". SOSP '95 Proceedings of the fifteenth ACM symposium on Operating systems principles. Copper Mountain Resort, CO, USA. pp. 237–250. 

Friday, June 2, 2017

Audi Virtual Cockpit

Introduction

In many traditional systems,  a touchscreen in center is the heart of infotainment with stripped-down menu, music info in the space between the gauge clusters.  When the driver wants to see the details, he/she has to move his/her eyes off the road and focus on the center of dashboard. To prevent drivers from being distracted from driving process, Audi Virtual Cockpit places all information in a digital gauge cluster. The crystal clear TFT screen has two operating modes: classic view and infotainment view. Classic view looks like traditional TFT gauge clusters with big gauges and information in the middle. While switching into infotainment view, gauges scale down and stay in the lower corners, freeing up large amount of space for displaying navigation map or main menu.

The Hardware

Audi car computer system is powered by two Nvidia Visual Computing Modules(VCM), each of which is driven by a Tegra 3 SoC.  One VCM renders 60 frame per second graphical contents to a 1440x540 resolution display while the other handles a second Navigation Plus system. A extra Head-up Display is connected to MMI to show information such as navigation symbols or information about the assistance systems.

Virtual Cockpit: Beating Analog

Audi Virtual cockpit includes every functionality but HVAC.  Analog gauges have the advantage that they come into play instantly when engine started. To beat analog, Audi virtual cockpit first starts in early mode,  displaying driver-critical information on another screen.  After few seconds, digital cluster come into functioning. QNX provides a platform for car-makers to build applications between the hardware and users.
Audi Virtual Cockpit, Copyright Audi AG

Center Display

Virtual cockpit is ideal if the driver is the only one in the car. A passenger usually wants to play with radio, media player. To complement the enjoyment of passengers, Audi offers a range of center display options, interacted with Audi MMI controllers instead of touchscreens.

Head-up Display

Head-up Display(HUD) projects important information, e.g. warning message with symbols and numbers onto windshield.  The driver perceives the information very quickly and he/she doesn't have to refocus his/her eyes from driving field of view, thus reducing driving risks.

Apple CarPlay

Apple's CarPlay is a smartphone projection system which integrates your iPhone into you vehicle, thus a safe way to make use of your iPhone while driving.  CarPlay integrates Siri to follow voice commands, but can also be interacted with vehicle's touchscreen and console knobs.

Interactivity

Audi virtual cockpit has two sets of redundant controls: one main set on the streering wheel and the other  on the center of dashboard.

Conclusion

Audi virtual cockpit is the first driver-oriented system with a combination design of digital instrument cluster and infotainment.