I am one of the OS developers for a military vehicle that utilizes vxWorks and Linux. It's honestly no different than other OS work out there. Documentation and help outside of WindRiver's official docs are more scarce, and open source support is smaller, but grasping how an RTOS works vs a GPOS isn't any major mental leap. If you can program in C and understand communication protocols like i2c, UART, SPI, CAN, etc. then it's not terrible.
Right now, we are looking at moving away from vxWorks and onto a Yocto-built Linux with the RT patches to the scheduler. From a requirements standpoint, the RT patches meet our needs for "real time" since our timings require more of a soft real time than a hard one. There's also way more support out there for Linux, and I am also slightly biased in that I am more of a Linux guy than a vxWorks guy simply due to familiarity and ease of troubleshooting.
This latest news with vxWorks is great, however. I actually sent this to management because we are attempting to figure out what direction to take as our current version is reaching EOL.
>Right now, we are looking at moving away from vxWorks and onto a Yocto-built Linux
This decision is probably out of your hands, but I'm happy to share a few words of caution. I've been the yocto distro maintainer at a large firm for about three years and I absolutely despise it. BMW released a slide deck about their experience with yocto, and it was mostly "it sucks." I read that recently and it matched my experience down to a t.
If you absolutely need third party commercial support, yocto is probably the only game in town, but if you don't, I would highly recommend looking at nix (which recently gained cross compile support) or buildroot.
I'm dead serious about avoiding yocto if at all possible, I've seen things I wish I could unsee. But that sounds about right for a military project.
EDIT: I put my email into my profile if you want to chat about yocto more in depth.
Embedded systems here, several projects using VxWorks through the years. Mostly safety motion controllers, robotics, medical and consumer FPGA processing boards.
Due to cost and availability of modern tools (compilers, testing, V&V, CI/CD and virtualization), there is a big trend right now to migrate those projects into RT Linux, which has come of age. I guess the support for modern languages from Wind River is their attempt to avoid losing customers or attracting new ones. They used to have an edge due to the certificated environments, but modern development and systems are becoming so complex (eg networking, cloud, etc) that using a pre-certified kernel is just a tiny bit of the certification process, and in many cases the complete system has to be validated anyway.
I used to when I worked at C-Cube/LSI Logic. We had a multimedia processor (MPEG-2/H.264 encoder and decoder) that was SPARC based. It was used in DVD recorders, D-VHS decks (if anyone remembers those), set-top boxes, satellite downlink receivers for cable TV headends and other MPEG applications.
My favorite part of VxWorks was WindView. It's an awesome tool that shows task execution.
Tornado. That brings me memories. ;-) IMHO it was much better than the current Eclipse-based IDE they have now. At the time, and especially with custom SoCs or CPUs like the SPARC you were using, there were very few options to do that. These days we have tools like Percepio's Tracealyzer [0] that targets a multitude of microcontrollers and RTOSes, and allows you to decouple a bit your development for a specific architecture. Many vendors also have similar tools for their offerings, for example the RTX viewer for ARM tools.
You at ALT or are there other players in that? In discussions about regulation, I often tell people one of the biggest ways of showing its value is that DO-178B caused a company to attempt a high-quality driver for Radeon that they wouldn't build themselves. ;)
I'm very curious about your experience in that market. Especially whether the GPU vendors give you enough information under NDA to make them reliable, if you mostly black-box it using a subset of their features, and so on. Also, the QA techniques you use in such scenarios. I think some of tricks on your end might be applicable to other types of hardware.
I'm at CoreAVI. As far as I know, ALT had some financial troubles that ruined the company (this was all before my time, I'm too young to have been involved in that :P ). Like half the senior employees are ex ALT employees who jumped ship once ALT started hemorrhaging money. We have a great relationship with AMD, we don't just do certified drivers for their chips, but we also temperture screen some of their GPUs and sell them in the industrial market. They give us a lot of documentation and will answer our questions directly. Although nowadays with all the stuff they release to the open source community I'm not sure if we are getting that much more information compared to everyone else. We do work with other GPUs such as the Verisilicon GC series, Intel HD, and most recently we started working with ARM. For Verisilicon & Intel, we don't really get as much support and we mostly work off the documentation they have released and reverse engineering on our part. The ARM partnership is fairly new so I can't speak too much about it, but from the outset they are looking to be a great partner like AMD.
For graphics APIs we implement a subset of OpenGL or Vulkan listed under their safety critical standards. We are part of Khronos and worked with them to define the OpenGL SC 2 standard and are currently working on defining the Vulkan SC standard. The saftery critical version of the APIs are a reduce subset that eliminate anything that would be more difficult to implement in certifiable code.
As for our QA process, its really split into two distinct things. There is just normal QA side with all the run of the mill testing and verification, and then there is the actual certification team who is responsible for meeting all the DO-178 requirements as defined by our process. Like a lot of other companies who do cert work, we don't create all the artifacts from the get go. There are a lot of defense contracts where they want "certifiable" but don't want to pay for the actual evidence, so we won't go out of the way to make it, if no one is buying it. We do have a strict coding standard and code reviews to ensure that any code checked in will actual be able to be certified, but certification is way more work than just writing the code. Once we have a paying customer for cert we will go through and write all the test cases, fill out all the requirements, and make sure every i is dotted and t are crossed.
I believe both Schneider and Allen Bradley use vxworks, but unless you are developing the PLCs you would never know, as a scada system supplier vxworks is not exposed to you just the features Rockwell or Schneider have built on top
