Vxworks

The name “VxWorks” is believed to have come from a word game called VRTX OS, created by Ready Systems (now this product belongs to Mentor Graphics ). In the early 1980s, the VRTX was a fairly new and raw product; it did not work too well. VRTX was only 4 KB in size and could not be used as a full-fledged operating system. Wind River has acquired the rights to distribute an enhanced version of VRTX called VxWorks. Improvements and extensions introduced by WindRiver allowed us to create a system that worked (for example, VXWorks had a file system and an integrated development environment ). Thus, the name VxWorks can mean English. VRTX now Works (“VRTX now works”) or eng. VRTX that Works (“VRTX that works”).

When it became clear that Ready Systems could terminate the VRTX distribution contract, Wind River developed its own operating system kernel, which replaced VRTX. The basic functionality of the new VxWorks core was the same as that of the VRTX.

VxWorks has a client-server architecture and, like most hard real-time OSes, is built on a microkernel technology. At the lowest uninterrupted kernel level (WIND Microkernel), only basic task scheduling and communication / synchronization control between tasks are performed. All other higher-level RTOS functions — memory management, networking, etc. — are implemented through simple lower-level functions. Due to such a hierarchical organization, the speed and determinism of the system core is achieved, it also makes it easy to build the necessary configuration of the operating system.

VxWorks can be configured for systems with hard hardware limitations, as well as for systems with advanced functionality. Individual modules of the system themselves can be scalable. When assembling the system, you can disable certain system functions that are not needed at the moment, you can also remove specific nuclear objects of synchronization if they are not necessary.

But, despite the fact that the system is configurable, it cannot be said that it implements a component approach, since all modules are built on the base core and cannot be used in other environments.

The VxWorks core has the following properties ^[4] :

• the number of tasks is limited only by memory;
• has 256 task priority levels;
• task planning is organized in two ways: priority preemption and cyclic;
• interaction of tasks occurs through message queues, semaphores, events and channels (for interaction between processes), sockets and remote procedure calls (for network interaction), memory sharing (used for data separation) and signals (for managing exceptional situations);
• several types of semaphores are provided for managing critical system resources — binary, computational, and mutually exclusive with priority inheritance;
• possible deterministic context switching.

VxWorks provides planning mechanisms based on POSIX ^[5] and its own planning mechanisms (wind scheduling). Both options have preemptive and cyclic planning. The difference is that the POSIX scheduling algorithms are applied in the process, and the wind scheduling is applied at the system level ^[4] .

All system tasks and applications in VxWorks use the same address space, which can lead to a violation of the stability of the system in the event of a failure of any application. The solution to this problem is achieved by installing a separately provided component VxVMI ^[6] , which allows each process to use its own virtual space.

To achieve fast external interrupt handling , interrupt service routines ( ISRs - interrupt service routines) in VxWorks operate in a special context outside of flow contexts, which gives an advantage in the time that is usually spent on context switching. The C function that the user attaches to the interrupt vector is not actually an actual ISR. Interrupts cannot directly access C functions. Instead, in the table of interrupt vectors, which is called by hardware, the ISR address is stored. The ISR performs the initial processing (stack preparation and saving of registers), and then the C-function is invoked, which was connected by the user ^[4] .

VxWorks has the following network tools ^[7] :

• TCP / zero-copy
• TCP / UDP / ICMP / IP ( IPv4 and IPv6 ) / ARP ,
• SLIP / CSLIP / PPP ,
• Sockets ,
• telnet / rlogin / rcp / rsh ,
• ftp / tftp / bootp ,
• NFS (client and server).

The VxWorks network tools also include the functions required when developing devices connected to the Internet:

• IP multicasting level 0.1 or 2;
• long fat pipe;
• CIDR (Classless Inter-Domain Routing);
• DHCP (Dynamic Host Configuration Protocol) in server, client and Relay agent configurations;
• DNS client (Domain Naming System);
• SNTP (Simple Network Time Protocol).

VxWorks supports the following routing protocols:

• RIPv 1 / v2 (Routing Information Protocol)
• OSPF (Open Shortest Path First) version 2.

VxWorks comes standard with RIP, OSPF is delivered as an additional product.

VxWorks supports Simple Network Management Protocol ( SNMP ) in both v1 and v2c versions. The MIB compiler (Management Information Base) supports MIB-II objects and extensions.

The standard interface for connecting portable network protocols to operating systems is the STREAMS interface. Under VxWorks, you can install any protocol that has a STREAMS implementation: both standard ( Novell SPX / IPX , Decnet , AppleTalk , SNA , ...) and specialized. OS VxWorks supports STREAMS version UNIX System V.4.

Additional networking features: WindNet

In 1994, Wind River Systems announced the WindNet program, according to which a number of manufacturers of communications software companies integrated their software products with VxWorks, thereby providing support (this is not a complete list) ^[5] :

• network protocols: X.25 , ISDN , ATM , SS7 , Frame Relay and OSI ;
• CASE- development tools for distributed systems based on ROOM (Real-Time Object Oriented Modeling) and CORBA (Common Object Request Broker Architecture) standards;
• Management of networks using MBD (Management By Delegation) and CMIP / GDMO (Common Management Information Protocol / Guidelines for Definition of Managed Objects) technologies.

The following file systems are supported in VxWorks ^[8] :

• MS-DOS-Compatible File System: DosFS
• Raw File System: RawFs
• Target Server File System: TSFS
• Network File System: NFS
• ISO 9660 (CDROM File System)
• Tape File System: TapeFs
• CIFS / SMB
• TrueFFS

From the point of view of software, a real-time multiprocessor system is of two types: asymmetric ASMP ( Asymmetrical MultiProcessing ) and symmetric SMP ( Symmetrical MultiProcessing ). With ASMP asymmetric multiprocessing, each microprocessor, and in the case of a multi-core microprocessor, each processor core executes its own OS copy, and the application developer is responsible for distributing processes (threads, tasks) across processors. In this case, the multiprocessor system is difficult to program, but it has the predictability (determinism) of real-time characteristics.

With symmetric multiprocessing SMP, an application programmer sees a multiprocessor system as a virtual uniprocessor, which greatly simplifies software development, but there is no 100% guarantee of predictability of performance due to the fact that the load between the processors is not distributed manually, but automatically.

Before the introduction of multi-core devices on the market of embedded microprocessors, there was practically no need for symmetric multiprocessing. The complexity of software development for loosely coupled multiprocessor systems was small, and the simplicity of programming was put in second place after the predictability of the behavior of the real-time system. Therefore, in versions VxWorks 5.x and 6.x, up to version 6.5, only asymmetric multiprocessing was supported, implemented as a VxMP library (supplied as an additional product), which allows communication between processors through objects in shared memory. With the advent of embedded multi-core microprocessors with strongly connected processor cores on a chip, the simplicity of software development has come to the fore, which has led to the need to support symmetric multiprocessing by embedded real-time operating systems.

Since version 6.6, released in November 2007 , VxWorks has begun to support symmetric multiprocessing SMP ^[9] . SMP support is included in the Wind River Workbench for VxWorks ^[10] and Workbench for On-Chip-Debugging integrated development environment. SMP support in VxWorks comes as an optional component. The following multi-core microprocessors are supported:

• ARM11 MPCore ( ARMv6 )
• Broadcom MIPS BCM1480
• Cavium OCTEON CN38xx
• Freescale MPC8641D
• Intel Dual-Core Xeon LV
• Intel Core Duo T2400
• Raza XLR 732

• Phoenix Mars Lander is a NASA vehicle designed to explore Mars .
• The Spirit , Opportunity and Curiosity probes, as well as the Mars Reconnaissance Orbiter, use VxWorks on the POWER platform. The system is used in other space missions, for example, Deep Impact .
• Planned use in the newest aircraft Boeing 787 and Boeing 747-8 .
• Communication equipment of many companies (for example, Nortel , 3COM , Alcatel , Samsung (OfficeServ 7400), Linksys WRT54G, NetGear WGR614).
• Some PostScript printers.
• Medical equipment of Siemens AG (in particular, magnetic resonance imagers ).
• Storage systems of various companies (ETERNUS DX from Fujitsu , E series from NetApp , DS series from IBM ).
• Control system of KUKA robotic complexes.
• ABB robots control system.
• Many other applications in embedded systems with high demands on reliability and response time.

VxWorks is compared with other real-time operating systems ^[11] .

• VxWorks operating system in the Internet, A.V. Demianov (RTSoft)
• VxWorks: Real-Time Operating System and Software Development Kit of RT, A. V. Demyanov, AVD Systems, Moscow
• Real-Time Operating Systems, I. B. Burdonov, A. S. Kosachev, V. N. Ponomarenko
• www.vxworks.ru
• rnd.cnews.ru - Real-Time Operating Systems for Avionics: An Overview

• Wind river systems
  • VxWorks 6.x
• VxWorks / Tornado II FAQ
• Vxworks cookbook