Requirements

Introduction

The Veho project aims to significantly streamline the development of Controller Area Network (CAN) applications by taking a set of input expectations and output requirements from a developer, and automatically handling the generation of an optimized program that satisfies those requirements on the target platform, saving development time over manually writing code to fulfill the sets of requirements for each CAN node a project might necessitate, with the potential for logic bugs and unintended performance bottlenecks to exist in each. This document aims to outline the core specification for the Veho project, including user requirements for which pieces of functionality should be publicly exposed and how they should be able to be used, and technical requirements for the constraints on how each exposed piece of functionality should function.

A background in the functioning of CAN systems is recommended before reading this document. Higher-level overviews of the individual facets of the project can be found in the other sections of the project wiki.

General Description

Given a set of expectations for the periodic and spontaneous inputs to and outputs from a CAN node, a set of technical capacities and limitations for the hardware platform which will be supporting the node, and a set of optional constraints detailing how each input and output should be processed and what information a user needs to retain about each, Veho will be able to generate freestanding code which, when run on the target platform, will handle the processing of each expected input and facilitate the dispatch of each expected output. Traditionally, an embedded software developer would have been expected to either hand-write the (typically verbose and arcane to those not familiar with the inner workings of the target platform) code to configure a target platform to their specifications or rely on a vendor-supplied low-level abstraction layer to do the same, after doing preliminary design and analysis work to determine how best to use the available hardware resources to accomplish their goals. As a case study for what this implies: semiconductor and software design company ARM Holdings estimated in 2016 that there was an average of 40-50 discrete processors in the average car, with higher-end cars commonly containing over 120 discrete processors. If the aforementioned design strategy was applied to each, the tedious and inherently complex nature of the processes involved may lead to an increase in overall development time and cost, along with a higher chance that logic bugs might exist in the produced code. By automatically generating the necessary configuration code for the target platform and automatically allocating hardware resources to most effectively carry out each required task, those time-consuming and complex steps are avoided, allowing the development of the core logic behind each CAN node to be prioritized.

Given the typically resource-constrained nature of embedded platforms, it is generally best to design software for those platforms to only make use of what's strictly necessary for the requirements of that software to be fulfilled. One of the core design goals of Veho, then, is to be zero-overhead as much as possible, allowing CPU time to be allocated to user code as much as possible. Another goal is to design the user requirement optimization areas of the project such that they are able to be formally verified, to ensure that safety and consistency guarantees for projects using Veho are met.

Requirements

As a user creating a node template, I...

• can specify a callback to be executed when a CAN frame with a specific message ID is received from the surrounding network
• can specify a callback to be executed when a CAN frame which has a message ID which matches another specific message ID when certain bits of the original are masked is received from the surrounding network
• can specify a callback to be executed when a CAN frame which has a message ID within a specific range of valid IDs is received from the surrounding network
• can specify access to a buffer of the last N CAN frames received through a specific frame matcher
• can specify the periodic transmission of a CAN frame to the surrounding network without developer intervention
• can specify the spontaneous transmission of a CAN frame to the surrounding network
• can specify an automatic response to a CAN remote frame with a specific message ID, requesting the transmission of a data frame
• can create software extensions to Veho to take advantage of platform-specific capabilities which may not be exposed through the CAN standard, without making any changes to the core library
• can be alerted to conflicting node configuration requirements that would put the system in an illegal or potentially undesirable state

As a user with a node template to be optimized, I can expect that...

• any two frame callbacks with the same frame matcher are combined into a single callback executing both actions
• a frame callback with an exact ID frame matcher and a frame callback with a range frame matcher, where the exact ID is within the range, can be combined to alter the range frame callback such that the exact callback is called alongside it if a frame with its exact ID requirement is received
• a frame callback with an range frame matcher and a frame callback with an exact ID frame matcher, where the range encapsulates the exact ID, can be combined to alter the exact frame callback such that the range callback is always called alongside it
• two frame callbacks with range frame matchers, where the two ranges overlap, can be combined to alter both callbacks such that one receives a frame with an ID within the other's sub-range, the other's callback is called alongside the first's callback
• two frame callbacks with exact ID frame matchers can be reduced into a single callback with a range frame matcher encapsulating the two, with internal logic to call the appropriate exact frame matcher callback if a frame with the ID of the upper or lower bound of the range is received, ignoring all "middle" IDs
• two frame callbacks with range frame matchers can be reduced into a single callback with a range frame matcher encapsulating the two, with internal logic to call the appropriate range frame matcher callback if a frame with an ID within either of the two ranges is received, ignoring all "middle" IDs
• a frame callback with an exact ID frame matcher and a frame callback with a range frame matcher can be reduced into a single callback with a range frame matcher, with internal logic to call the exact ID callback if a frame with the exact ID is received, and to call the range callback if a frame within the range is received, ignoring all "middle" IDs

Glossary

• CAN Node: an individual processing entity connected to a Controller Area Network, capable of performing specific tasks in response to messages from other nodes, and transmitting information back into the network as necessary
• Node Template: a construct which specifies the required behavior of a CAN Node without actually generating the required code to do so; a blueprint for an implementation
• Frame Matcher: a predicate that a CAN frame must match for it to be processed by a specific callback. This might be an exact match for its ID, whether its ID falls within a specific ID range, or another requirement
• Frame Callback: a block of code which is executed when a frame matching a specific frame matcher is encountered