PROTECTOIN OF TRANSMISSION LINES USING GPS

  QNX - Neutrino RTOS.ppt (Size: 649.5 KB / Downloads: 0)
Design Goals
Primary goal: Deliver open systems POSIX API in scalable form
suitable for wide range of systems:
Tiny resource-constrained systems
High end distributed computing environments
mission-critical applications:
robust architecture is fundamental:
flexible and complete use of MMU hardware
An embeddable POSIX OS?
The myth:
“if you scratch a POSIX operating system, you’ll find UNIX beneath the surface!”
A POSIX OS is therefore too large and unsuitable for embedded systems.
The fact:
POSIX is not UNIX
POSIX standards are rooted in existing UNIX practice…
POSIX working groups explicitly defined the standards in terms of “interface, not implementation.”
nontraditional OS architectures can provide a POSIX API without adopting the traditional UNIX kernel.
POSIX systems look very much alike
many of the same functions, utilities, etc
differences in performance or reliability
Architecture makes the difference
Product scaling
including or omitting the particular processes that provide the functionality required
use a single microkernel OS for a much wider range of applications than a realtime executive
advantages to scalable approach include:
portable application code (between product-line members)
common tools used to develop the entire product line
portable skill sets of development staff
reduced time-to-market.
Why POSIX for embedded systems?
Problem with realtime application development: each realtime OS comes equipped with its own proprietary API
realtime marketplace show heavy use of inhouse proprietary operating systems
POSIX represents a chance to unify this marketplace
Many POSIX standards.
Most interest to embedded systems developers:
1003.1 —defines the API for process management, device I/O, filesystem I/O, and basic IPC
Realtime Extensions— defines a set of realtime extensions.
Consist of semaphores, prioritized process scheduling,…
Threads—further extends the POSIX environment to include the creation and management of multiple threads of execution within a given address space.
Additional Realtime Extensions—defines further extensions to the realtime standard.
Facilities such as attaching interrupt handlers are described.
Application Environment Profiles— defines several AEPs (Realtime AEP, Embedded Systems AEP, etc.) of the POSIX environment to suit different embedded capability sets.
Represent embedded OSs with/without filesystems and other capabilities.
Specific advantages to applying POSIX:
Multiple OS sources
Hardware manufacturers don’t choose a single-sourced hardware component: risks if that source discontinues production
Manufacturers shouldn’t be tied to a single-sourced, proprietary OS simply because their application source code isn’t portable to other OSs
By building applications to the POSIX standards, developers can use OSs from multiple vendors.
Application source code can be readily ported from platform to platform and from OS to OS, provided that developers avoid using OS-specific extensions.
Portability of development staff
Using a common API, programmers experienced with one realtime OS can directly apply their skill to other projects involving other processors and operating systems
Programmers with UNIX or POSIX experience can easily work on embedded realtime systems, since the nonrealtime portion of the realtime OS’s API is already familiar territory
Development environment: native and cross development
With the addition of interface hardware similar to the target system, a workstation running a POSIX OS can become a functional superset of the embedded system
Result: the application can be developed on the self-hosted desktop system
the programmer doesn’t need to worry about platform-specific endian, alignment, or I/O issues.
Why QNX for embedded systems?
Main responsibility of an operating system: manage a computer’s resources
All activities in the system— scheduling application programs, writing files to disk, sending data across a network, and so on —should function together as seamlessly and transparently as possible
Some environments call for more rigorous resource management and scheduling than others.
E.g. Realtime applications depend on the OS to handle multiple events and to ensure that the system responds to those events within predictable time limits.
The more responsive the OS, the more “time” a realtime application has to meet its deadlines.
QNX for embedded realtime applications
Can be scaled to small sizes and provides
multitasking
threads
priority-driven preemptive scheduling
fast context-switching
QNX delivers these capabilities with a POSIX-standard API; there’s no need to forgo standards in order to achieve a small OS
QNX is also flexible:
Developers can easily customize the OS to meet the needs of their applications
From a “bare-bones” configuration of a microkernel with a few small modules to a full-blown network-wide system equipped to serve hundreds of users
QNX lets you set up your system to use only those resources you require to tackle the job at hand
QNX achieves its degree of efficiency, modularity, and simplicity through two fundamental principles:
microkernel architecture
message-based interprocess communication
Microkernel Architecture
Microkernel:
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.
The microkernel itself lacks filesystems and many other services normally expected of an OS —those services are provided by optional processes.
The real goal in designing a microkernel OS is not simply to “make it small.”
A microkernel OS embodies a fundamental change in the approach to delivering OS functionality
Modularity is the key, size is but a side effect.
To call any kernel a “microkernel” simply because it happens to be small would miss the point entirely
Since the IPC services provided by the microkernel are used to “glue” the OS itself together, the performance and flexibility of those services govern the performance of the resulting OS
With the exception of those IPC services, a microkernel is roughly comparable to a realtime executive, both in terms of the services provided and in their realtime performance
The microkernel differs from an executive in how the IPC services are used to extend the functionality of the kernel with additional, service-providing processes
OS is implemented as a team of cooperating processes managed by the microkernel
User-written processes can serve both as applications and as processes that extend the underlying OS functionality
The OS itself becomes “open” and easily extensible
user-written extensions to the OS won’t affect the fundamental reliability of the core OS.
As the following diagrams show, a true microkernel offers complete memory protection, not only for user applications, but also for OS components (device drivers, filesystems, etc.)
The OS as a team of processes
The OS consists of the small Neutrino microkernel managing a group of cooperating processes
As the following illustration shows, the structure looks more like a team than a hierarchy, as several “players” of equal rank interact with each other through the coordinating kernel.