Scalable Hardware-Software Interface Answers Overlooked AV Testing Need

Polysync’s Prism platform translates commands and data written in programming environments to inputs an automated vehicle can understand.

AV developers start with Polysync’s large and capable Developers Edition platform; as the code is deployed to more vehicles, the hardware’s footprint gets smaller. (Polysync)

In 2016, Oregon-based PolySync introduced DriveKit, a set of open-source hardware and software tools that enabled skunkworks engineering teams to electronically assume control of a vehicle’s steering, accelerator and brakes. The kit makes possible autonomous-vehicle development using vehicles such as the Kia Soul for an accessible $1,000 price. But an Arduino board connected to an OBD port, bringing in signals from an aftermarket camera or sensors, does not have the robustness required for automotive-grade commercialization.

The top of the system-on-module translation device for the Fleet Edition. (Polysync)

In the subsequent four years, Polysync gained insights about AV development from its list of customers – a group of increasingly sophisticated companies developing and testing vehicle automation. So, in January, Polysync unveiled not just a new kit, but an entire platform suitable for major automakers and startups to turn available passenger vehicles into self-driving solutions that can be commercialized.

The Polysync hardware-software platform, dubbed Prism, serves as a “vehicle interface layer” –middleware that sits between the AV technology stack and the vehicle. An AV developer typically will have a compute layer, sensor-fusion layer and an application layer for functions such as path planning. Polysync doesn’t do any of that. It strictly provides the translation layer to interface with the vehicle. “We have full reflective control of the vehicle,” said Greg Drew, chief executive at Polysync.

The Prism platform solves a seldom-discussed problem: AV companies primarily are focused on tasks such as AI, perception or controls. But to test their solutions in existing production vehicles, they need to translate commands and data written in programming environments, such as Simulink or Baidu Apollo, to inputs that the vehicle can understand.

A lot of time and engineering dollars might be invested to create an interface to one vehicle, but it has to be recreated when applying that same automated-driving system to a different model or trim level. “Let’s say you line up 10 vehicles, whether they came from 10 different companies, or all 10 vehicles came from three separate companies. None of those vehicles are the same,” said Drew. “Sending the command to ‘depress-brake’ for vehicle number one is different than the command to depress-brake for vehicle number two, and so on.”

A graduated approach

Greg Drew, Polysync CEO. (Polysync)

The same re-do problem exists when an AV project graduates from early stages of development tested on a track to the much higher safety requirements needed for roadways. “There are countless companies right this minute that are panicked because all the work they’ve done for the last couple of years will never be approved by government agencies,” said Drew.

To avoid the need to re-write code as an AV company moves through its product lifecycle, it can start with Polysync’s relatively large Developers Edition – a system-on-module and software developers kit (SDK). The module, known as Spark, plugs into the standard vehicle harness and provides a full set of connectors the vehicle requires. “In early stages, you have a fire-breathing enclosure of many, many needs and capabilities,” said Grant Ray, Polysync’s chief marketing officer.

When the code is tweaked and the sensor stack is refined enough to deploy to multiple vehicles for track testing, those models can migrate to the Polysync’s smaller Fleet Edition. And when the time comes for mass deployment to public roads, the company can transition the onboard hardware to the unit with the smallest footprint, the OEM Edition. By that time, safety requirements already are baked into the cake. “Our entire product is built on automotive-grade parts that subscribe to industry standard ISO 26262,” said Drew.

Polysync also is in the process of obtaining Automotive Safety Integrity Level D (Asil-D) certification, the most stringent and redundant level of safety defined in ISO 26262. As of January, Prism supports the Chrysler Pacifica, Kia Niro, Kia Niro EV and several long-haul trucks, farming, warehouse and mining vehicles. But the company says the list of compatible vehicles is quickly growing.