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.
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.
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.
My favorite part of VxWorks was WindView. It's an awesome tool that shows task execution.
It's the defacto standard in defence engineering.
having said that, there is nothing special about vxWorks, skills learnt there apply directly to other RTOS's.
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.
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.
Does that answer all your questions?