1. Charles Eagan, Engineering Vice President ceagan@qnx.com
QNX Software Systems
Charles Eagan,
Engineering Vice President

2. All content copyright QNX Software Systems
QNX: The choice of Networking Leaders
All content copyright QNX Software Systems

3. Stable and Healthy Markets
Our Markets
Automotive
Consumer
Industrial
Automation
Military
Medical
Networking
Networking
Stable and Healthy Markets
Our Fastest Growing Market
QNX is the #1 for automotive.
140 car models with QNX
Our Largest Market
Most customers today
Most revenue today
Our Largest Potential Market
2nd fastest growing market
Largest customer (Cisco)
Largest potential revenue
Even though we specialize is certain markets, we know that there is a common layer of challenges that every developer encounters:
- Reliability – Developers want to ensure the system they build is highly reliable
Scalability – Will their system be able to grown and scale – without causing any interruption to the system?
Tools – Developers are faced with getting their product to market on time – productivity is essential and that is why FULLY integrated tools – that come right out of the box is key in accelerating development
Upgradeability and Performance – Once systems are in the field, companies may need to upgrade system without system failure.
QNX started out in the Industrial Automation market
Why QNX? Broad peripheral support on x86 and reputation for reliability
Our reputation for reliability and support for multiple processor families expanded our reach
Consumer electronics
Networking
Automotive
Demand for QNX is now growing in the military market
QNX: An excellent Networking partner
Infotainment suitable for consumer
All content copyright QNX Software Systems

4. All content copyright QNX Software Systems
Networking Decision
How does a networking company decide on an operating system strategy?
Many executives are not aware of the productivity implications of a commercial operating system and development tools
Engineers that are aware of the implications are often not able to significantly influence decisions
The time window where an operating system can effectively be transitioned is narrow
Strong leadership and determination is required to make an effective transition
All content copyright QNX Software Systems

5. Why Companies Choose QNX
Customized
Business
Terms
Synergistic
Engineering
Culture
Flexible
Operations
Model
Advanced
Technology
Suite
Competitive
Roadmap
Tools and
Development
Aid
All content copyright QNX Software Systems

6. All content copyright QNX Software Systems
Development Dynamics
Cisco choose QNX as a strategic partner in the 1996/1997 timeline
This is interesting as at this time QNX was primarily an Intel based technology and Cisco was mostly MIPS based
The skills and abilities of the QNX team combined with engineering chemistry and aligned roadmaps and vision led to the creation of an innovative joint collaboration
The use of QNX technologies has evolved into over 10 different groups within Cisco
All content copyright QNX Software Systems

7. Initial Public Announcement
All content copyright QNX Software Systems

8. QNX Ecosystem Catalyst 6k Ethernet switch CRS-12000 QNX
Core Technology
and
Tools Suite
Cisco family of service ports adapters
CRS-1
Many other hardware platforms
Many other hardware platforms
Many other hardware platforms
All content copyright QNX Software Systems

9. Important Technology Areas
Highly Available Fast Architecture
Flexible Scaleable Architecture – Fully distributed or monolithic
Secure
Using/following technology and development standards
IEEE
POSIX/Unix
Java/C++/C/gcc
Flexible
Endian abstraction
Processor neutral – MIPS/PPC/Intel
Productivity Tools
All content copyright QNX Software Systems

10. Scalable Solutions for Cisco
QNX Neutrino used in applications from framer interface support to CRS-1
From 1 CPU to thousands networked and functioning as a single compute resource
QNX Confidential. All content copyright QNX Software Systems.

11. Industry Leading Multi-Core
Symmetric Multiprocessing
Multi-core optimized applications
Resource sharing handled by OS
Transparent scaling beyond dual core
The QNX solution enables software transition to multi-core processors:
Proven OS support for any multi-core processing model
Full suite of development tools to characterize and optimize multi-core applications
Expert professional services and support
Wide range of multi-core board support packages
Design Needs
Asymmetric Multiprocessing
Support existing software base, non-optimized uni-processor approach
Heterogeneous OS approaches require AMP
Sharing resources in AMP is non-trivial, scaling beyond dual core is even tougher
Bound Multiprocessing
Migrate existing software base
Mix existing applications with multi-core optimized applications
Transparent scaling beyond dual core
QNX Pioneer
QNX Confidential. All content copyright QNX Software Systems.

12. Highly Available Architecture
The best availability architecture in the world
Process communicate by sending messages
Forwarding
Shared memory
large data sets and hardware access
Process
Manager
File
System
BGP
ISIS
Ingress
Egress µK
Message Bus
Microkernel
Forwarding
Processes communicate via messages
Messages are moved by the kernel
Data over-run is prevented
Provide a safe connection between processes
Messages provide a “clean” interface between processes
You can test a component by testing the set of messages it supports
You can upgrade components based upon this clean interface
Message passing encourages the design of well formed reliable systems
Failing components are isolated from each other allowing recovery and/or restart
Message passing provides one uniform IPC mechanism
Applications talk to each other by messages
Applications talk to file systems and drivers via messages
All POSIX IO is built on-top of messages
Monolithic systems have
100’s of private kernel calls for IO to file systems and drivers
Application specific mechanisms for communicating to each other
Each and every method needs to be security verified
Using Messages:
Cleanly decouples processes
POSIX calls built on messages
Memory Protection
The most important technology that is mandatory for true system availability
90% of all system failures are due to foreign memory scribblers
All content copyright QNX Software Systems

13. Flexible Architecture – Fully Distributed or Monolithic
Message
Bridge
internet
Adding new services on any CPU can transparently provide that service to all CPUs
Process
Manager
File
System
Networking
OSPF
BGP
MPLS
System functions as one single router
seamlessly across many individual
loosely or tightly coupled CPU’s µK
Message Bus
Microkernel
Traffic
Engineering
Applications and Servers become network distributed without any special code.
You gain unified access to all remote hardware and software resources with permission checking.
Process
Manager
Netflow µK
Custom
Application
Bridging the kernel allows messages to flow transparently from one message bus to another over a variety of transports
(Ethernet, MOST, custom switching fabric, Internet, …)
All content copyright QNX Software Systems

14. Distributed Computing Architecture
Routing controller
Distributed Unified Router
Route Processor
Line Card/Forwarded Plane
MPLS
CPU
CPU
SMP
BMP
AMP
DMP
Transparent
Secure
Distribution
Protocol
OSPF
BGP
BGP
Applications can
seamlessly move to any linecard
All content copyright QNX Software Systems

15. Auto-discovery and Load Balancing
Message Bridge (Ethernet, fabric, interconnect…)
Flash File System
Database
Application
Microkernel
Message Queues
Networking Stack
Internet
Message-Passing Bus
QNX Transparent Distributed Processing
Distributed POSIX model
Framework for dynamic interconnection of hardware and software among remote nodes
Global Name Service for discovery of new hardware and applications
Stop applications on one node and restart on a new node
No reboot required
All connections are maintained transparently
In use extensively in CRS-1
QNX Confidential. All content copyright QNX Software Systems.

16. All content copyright QNX Software Systems
Security Principles
Separation of privilege
Different privilege levels available to different applications
Lowest level of privilege required assigned to application
Complete mediation
Check all accesses — no exceptions
Fail-safe defaults
Lowest level of privileges/access assigned by default
Design
“Object oriented” design principles
Abstract, modularize, encapsulate, isolate
Very helpful if the OS “enforces” these principles
Resource protection at the application level
Memory, CPU cycles, hardware registers, peripherals, etc.
Operating system architecture can greatly affect how (or even if) these principles can be applied
All content copyright QNX Software Systems

17. All content copyright QNX Software Systems
Fault Removal and Recovery: Availability
Recovery capability can be characterized by a systems “availability”
The probability that a system or subsystem will perform its intended function at a given instant of time.
MTBF
MTBF + MTTR
Availability =
MTBF is mean time between failures and MTTR is mean time to repair
99.999% availability (five nines) = fewer than 5.25 minutes of annual downtime (scheduled or unscheduled)
Networking companies and industry watchers constantly monitor these statistics
All content copyright QNX Software Systems

18. System Guarantees: Increase Availability
Increase MTBF
Test and debug (repeat often!)
Most OSs provide many tools to increase MTBF
Also reduce MTTR
Detect, contain, recover from error
Availability approaches 100% as MTTR approaches 0
Recovery Scenarios
System reboot (real-time executive, monolithic kernel)
Seconds to minutes to recover
Restart service (microkernel, monolithic application)
Milliseconds (<< 1 second) to recover
Combination of microkernel + recovery framework
Much easier to attain “five nines” availability
All content copyright QNX Software Systems

19. High Availability Framework - CPM
Developed with Cisco as lead customer
High Availability Framework
Construct custom failure recovery scenarios
Design your system to reconnect instantly and transparently to minimize downtime
QNX Confidential. All content copyright QNX Software Systems.

20. All content copyright QNX Software Systems
Highly Available - CPM
CPM
App
Guardian
CPM Checkpointed State
High Availability Recovery Framework (CPM: Critical Process Monitor) monitors components and handles recovery of component failures
Guardian process provides software failover to ensure that the high availability process doesn’t become a single point of failure
Client-side library allows components to reconnect instantly and transparently
User can easily add state information and customize recovery procedure
Can also provide heartbeat services to detect component hangs — this allows the system to monitor itself
Once a fault has been detected, the RTOS also needs to provide notification so the problem can be corrected. With a high availability manager, the RTOS can monitor system components and effectively manage recovery on component failure (crashes and hangs).
A HAM provides:
Checkpointing services
Heartbeat services to detect component hangs – this allows the system to monitor itself and recover from faults automatically
All content copyright QNX Software Systems

21. Critical Process Monitoring
Shared Memory State Information
Critical Process Monitor (CPM)
CPM Guardian
Application A
Driver
Application B
Driver
Microkernel
1. Driver faults due to illegal access to memory outside memory-protected space
2. Kernel notifies CPM of process fault
3. Debug information on faulting process is collected (standard core file)
4. Driver exits and returns all resources to system; IPC channel destroyed
5. CPM restarts new driver
6. Driver IPC channels are reestablished by CPM client library
7. Driver requests information on last state checkpoint from CPM and service is restored
All content copyright QNX Software Systems

22. Dynamic Upgradeability
Process Manager
File System
Protocol Stack
Audio Driver
Graphics Driver
Microkernel
Message Bus …
Application
Microkernel
is the only trusted
component
Applications, File Systems and Drivers
Exist as processes on a message bus
Reside in memory-protected address space
Can be started, stopped, added, removed, relocated and upgraded without rebooting
Cannot corrupt other software components
QNX Confidential. All content copyright QNX Software Systems.

23. Momentics: Eclipse Leader and Founder
Scalable, Reliable and High Performance
Out-of-the-box support for:
Multiple hosts, targets, languages and BSPs
Optimizing compilers
Compatible with all 3rd party Eclipse plug-ins
QNX Confidential. All content copyright QNX Software Systems.

24. QNX: Introducing Adaptive Partitioning
A critical technology for networking applications
All content copyright QNX Software Systems

25. Introducing Adaptive Partitioning
What is Adaptive Partitioning?
Adaptive partitioning is a new QNX product that extends the Neutrino RTOS
Allows you to build secure compartments or “partitions” around a set of applications or threads
Partitions enforce CPU guarantees for applications, controlled by easy to use budgets
Why is it Adaptive?
Patent-pending design ensures all available CPU cycles are given to partitions that need processing time – no CPU cycles wasted
Provides performance advantage by permitting full processor utilization to accommodate spikes in demand
Easy to get started
No changes to how designers work today
POSIX programming model for the same, familiar design, programming & debugging techniques
No code changes are required to implement partitions
All content copyright QNX Software Systems

26. Microkernel Architecture for Security
Graphics
Network
Disk
Serial
Audio
QNX
Neutrino
Microkernel
Application
Application
Application
Applications and Drivers
Are processes which plug into a message bus
Reside in their own memory-protected address space
Cannot corrupt other software components or kernel
Can be started, stopped and upgraded on the fly
Failures in drivers do not require system restarts
With Neutrino, the microkernel and the process manager are trusted in the system. Everything else, from device drivers to file systems to applications are separate, memory protected processes. Think of the microkernel as a software bus that each program running in the system plugs into, allowing them to communicate with each other in a safe, reliable manner. This separation of components is key to detecting and containing system faults and attacks from rogue software. Memory is protected to ensure that malicious processes cannot overwrite kernel, driver or other application memory. The microkernel also provides priority-based thread scheduling to provide a POSIX multi-threaded execution environment. This microkernel architecture forms the foundation to build secure, reliable systems. As you will see, this concept is further enhanced when adaptive partitioning is added….(next slide)
ARM,
MIPS, SH4,
PowerPC, Xscale, x86
All content copyright QNX Software Systems

27. Introducing Adaptive Partitioning
10%
70%
20%
File System
Core Application
Add-On Application
Add-on Application
Device Driver
Core Application
Core Application
QNX Neutrino
Microkernel
QNX® Neutrino ® RTOS provides the basic structure
Application and OS service encapsulation with message passing
Hardware memory protection for security and reliability
Let’s start with an existing system that already uses the QNX Neutrino RTOS. This provides the basic structure for processes, messaging and memory protection as we saw in the previous slide….(next)
Adaptive partitioning is a new scheduling approach that can be added to any system using the QNX Neutrino RTOS. You can think of adaptive partitioning as an extension to the QNX Neutrino micro-kernel.
The partitions can be defined at design time or at runtime, depending on the desired approach. When creating a partition, you define which processes and threads belong in a partition and then assign a CPU budget to a partition. The CPU budgets are expressed in percent, and the budget of all partitions must add up to 100%. The partitioning scheduler will ensure that each partition receives it’s budgeted share of CPU time in a specified time window. In this example, the File System and a Device Driver are grouped into a partition. These share the
Adaptive partitioning extends the Neutrino micro-kernel to provide secure partitions and guaranteed CPU time
A collection of processes and threads make up a partition
A partition is assigned a percentage of CPU time, averaged over a time window
Overlays on existing thread scheduling
All content copyright QNX Software Systems

28. All content copyright QNX Software Systems
Maximum Performance
70%
Application
Partition
20%
Untrusted
Partition
10%
I/O Partition
QNX Neutrino
Microkernel
File System
Device Drivers
Core
Application
Core
Application
Add-On
Networking
Core Application
Add-On
CPU guarantees for partitions at full
system load
10%
70%
20%
Idle CPU time
Dynamic allocation of CPU cycles when not fully loaded 5%
30%
55%
10%
CPU Utilization
All content copyright QNX Software Systems

29. Understanding “Adaptive”
Management
Interfaces
(CLI, SNMP)
Routing &
Forwarding
Maintenance
10%
70%
20% 5%
90% 5%
Processing
Load
Scenarios
We just looked at how adaptive partitioning provides a level of security by containing the amount of CPU consumed by a particular partition. By adding partitions, you can limit the amount of CPU time consumed by groups of applications.
A natural question arises – this is good, but what if you budget 40% of CPU time for a partition (for example the car animation partition) and not all of the CPU time budge is used by the partition. Don’t the rest of your applications run slower because they have less CPU time…. What if they have something that needs to be done. This question is the essence of the “adaptive” part of adaptive partitioning.
Let’s work through an example of how this works. Take an automotive navigation system that has a user interface, a route calculation subsystem and a diagnostics and data acquisition subsystem. Depending on what is happening in the car at any given moment, these subsystems consume more or less CPU time.
For example, when the car is started, ideally, you would want as much CPU time dedicated to diagnostics/data collection and intialization as possible. In this case you also need to give some CPU time to the user interface to ensure the user is given some visual feedback. Since the car is stopped and there is no known route yet, the route calculation requires no CPU time.
The next scenario is when the car is running and stopped – no route has been assigned. A bit more processing time is required for the UI and diagnostic subsystems, non for the route calculation and there is a lot of idle time.
When the driver starts requests a route and is driving at a constant speed, there is a bit more time consumed by the UI and diagnostics and the routing system is running to ensure the driver is traveling in the right direction and updating the UI as appropriate.
The last scenario is when the user makes an incorrect turn and the routing subsystem must alert the user and recalculate an alternate route to the destination. In this case, you want to ensure the diagnostics / data acquisition is getting as much CPU time as required and devote as much processing time as possible to the re-route calculation and the user interface.
As you can see, in this example, the CPU load of various subsystems changes over time depending on the driving situation.
(next slide)
Idle Time
80%
10%
10% 5%
95%
All content copyright QNX Software Systems

30. Partitioning to Contain Threats
Without Partitioning
Rogue software can starve core applications of CPU time
Distributed DOS attacks can busy your system with network processing
With Partitioning
Create OS enforced partitions to ensure critical system resources are protected
Contain threats and protect core applications and services
QNX Neutrino
Microkernel
Control Plane Attacked
Denial of Service Attack Contained
Network
Management
File
System
Core
Application
Rogue add-on
contained
Add-On
Device Drivers
Core Application
Control Plane
Protocols
Add-On
10% 5%
25%
Adaptive Partitioning
CPU Time Guarantees
50%
All content copyright QNX Software Systems

31. CPU Guarantees: Increase Availability
Guaranteed CPU time for recovery actions
Failed components isolated, contained and cannot impact fault recovery processes
Guaranteed CPU time for notification and user intervention
Ensure that remote user interfaces remain operational and cannot be starved
QNX Neutrino
microkernel
Networking – DOS Attack Contained
Remote
Interface
Device Drivers
Core
Application
User Interface
Alarm Notification
Networking
File System
Core Application
Fault Recovery
Automatic Recovery
Reduce MTTR
All content copyright QNX Software Systems

32. Software Complexity Development View
Management
Interfaces
Large teams, multi-site development
Geographic and time zone separation
Division of responsibilities, functional areas and expertise
Differing designer skill sets
License and integrate 3rd party technologies to reduce development costs
Lack of developer control of 3rd party technology
Parallel development, followed by system integration & verification
Maintenance
Routing &
Forwarding
All content copyright QNX Software Systems

33. Building Complex Systems System Integration
System integration is a significant portion of the overall project schedule
Always on the project’s critical path
Problems detected late in design cycle are the most costly
Initial verification cost to find bugs
Typically hold up whole project
Require system experts to troubleshoot and resolve
Cost of re-implementation, re-test
Design changes introduced late add project risk
Typically, band-aid solutions are used to limit churn and maintain schedule
Net effect is to reduce product quality and performance
Typical problems that occur at integration time are typically related to performance, memory corruption and process starvation
All content copyright QNX Software Systems

34. All content copyright QNX Software Systems
Conclusion
QNX remains committed to the markets that made it successful and is aggressively expanding into new markets to fuel future growth.
Our technology roadmap will continue to show clear leadership and will address the needs of our markets.
All content copyright QNX Software Systems