Apex.AI, Inc. was founded by Jan and Dejan in 2017. Jan has been working on autonomous vehicles since starting his Ph.D. work in 1997 and Dejan has been working on robotics and software frameworks since 2008. Both Jan and Dejan have contributed to ROS since its inception in 2008: During his Ph.D. work at TU Munich, Dejan developed ROS-based software. Later, after joining Bosch in Palo Alto, he worked closely with Willow Garage on the core ROS codebase. During that time, Jan was at the helm of Bosch's robotics and autonomous driving labs in Palo Alto. He coordinated Bosch's contribution to ROS in the PR2 Beta program of Willow Garage, and his lab was the only corporate contestant that was awarded a PR2 platform for research. ​ Based on the observation that many companies apply ROS to safety-critical systems without having a thorough understanding of the requirements and implications, the duo decided to start Apex.AI to provide Apex.Grace as a robust and reliable version of ROS 2 for safety-critical systems including functional safety certification and professional support.

We do not reinvent the wheel. Instead, we take ROS, which is a great and established open framework for robotics and autonomous systems R&D, and make it robust and reliable for use in automotive and other safety-critical applications. Specifically, we provide Apex.Grace as a robust and reliable version of ROS 2 for safety-critical systems including adequate certification and professional support, both of which are outside of the scope of an open-source project.

The correct spelling of our company name is Apex.AI. The full legal name of our US entity is Apex.AI, Inc. and the full legal name of our German entity is Apex.AI GmbH. Apex.AI GmbH is a wholly-owned subsidiary of Apex.AI, Inc.

In Latin, the word Apex means 'summit, peak, tip, top, extreme end, or highest honors’ (source Wikipedia). In geometry, an apex (plural apices) is the vertex which is in some sense the "highest" of the figure to which it belongs (source Wikipedia). In motorsport, when driving the optimal racing line, the apex is the point at which an inner tire of the vehicle touches the inner edge of a curve (source Wikipedia). In ecosystems, Apex species are central to the functioning of ecosystems and the maintenance of biodiversity (source Wikipedia).

ROS stands for Robot Operating System, but it’s not really an operating system. It is better understood as a meta-operating system or Software Development Kit (SDK) that is used to develop robotics applications: it provides open-source software, libraries, and tools that are needed to develop, debug, test, and deploy your robotics application. ROS is developed and maintained by our friends at Open Robotics.

Apex.Grace is a fork of ROS 2 that has been made so robust and reliable that it can be used for the development and production of highly-safety critical systems such as autonomous vehicles, robots, and aerospace applications. Apex.Grace is API-compatible to ROS 2. In a nutshell, Apex.Grace is an SDK for autonomous driving software and other safety-critical mobility applications.

Apex.Grace is enterprise software. It’s available to professional user under a commercial license subscription

No, Apex.Grace is not open-source. Apex.Grace is sold under a proprietary license. ROS 2 is open-source and Apex.Grace is API-compatible to ROS 2. A lot of the bugs we fixed in ROS 2 in the process of forking ROS 2, we have contributed back into open-source ROS 2.

We believe that developing safe and secure autonomous driving systems is an incredibly challenging problem. We further believe that this challenge requires a diverse ecosystem of technologies, components, systems, products, and of course companies building these. We strive for an open ecosystem in which customers can select best-in-class hardware components, software modules, computers, sensors, actuators, and services, and combine these into a stack that works best for their individual problems. We are providing components for this ecosystem and not a closed full-stack system.

The safety of functionality of technical systems is described in technical norms, i.e. IEC 61508 in general, ISO 26262 for automotive, and DO-178B for aerospace systems. These norms stipulate the required safety level depending on the safety criticality of the intended functionality and the development process to get to that level. ​ Apex.Grace are software components to be used as parts in safety-critical autonomous mobility systems. Apex.Grace is certified as a Safety Element out of Context (SEooC) up to ASIL D which represents the highest functional safety level in ISO 26262. ASIL stands for Automotive Safety Integrity Level. ​ Apex.AI is working with TÜV NORD, one of the most reputable assessors in the field, to achieve certification for Apex.Grace.

We use established automotive software development practices, e.g. as described in part 6 the automotive functional safety norm ISO 26262, which has been employed for years in the development of software for small micro-controller-based vehicle computers, such as engine ECUs or ESP ECUs. ​ We are now applying the rigorous software development standards for automotive software to the development of highly complex robotics and autonomous driving software. In practice, this means that we have substantial experience in writing software with static memory, non-blocking synchronization primitives, and real-time logging while also knowing how to abstract them away behind easy-to-use ROS 2 APIs.

If you are working on a demo or R&D prototype, then you likely do not require certification. If you are working on a product, then you may (or may not) require certification depending on the regulatory and product liability-related requirement in your market. Independent from obtaining actual certification, you (presumably) will want to achieve robustness and reliability of both a) your software implementation (as described in ISO 26262 part 6 and 8) and b) your functional performance (as described in ISO/PAS 21448:2019), so that your work product fulfills your customer expectations. While building a complex robotic system that has a robust, reliable, and real-time capable software stack you will likely find that a set of implementation requirements, coding requirements, and guidelines is required. You will also find that those requirements and guidelines are very similar to ours and hence similar to the ones described in functional safety guidelines and best practices. You could of course also choose to reinvent the software wheel, come up with all those requirements and guidelines on your own, and spend a multiple of the amount of time and resources, or you could use the collected wisdom of years of automotive functional safety expertise and follow what others have written down for you in ISO 26262, part 6 and 8. Whether you then choose to also get certification (besides following the guidelines that lead to certification) is again your choice. The Apex.Grace value proposition is that the complexity of these (admittedly) tedious software implementation best practices is abstracted into easy-to-use APIs from Apex.Grace, so that you and your developers don’t have to be an expert in embedded, real-time, and functionally safe programming, but can rather focus on creating functional performance.