Safety-certified tools Tools for Automotive Applications C-STAT Static analysis C-RUN Runtime analysis Debugging and trace probes
The team has been using IAR Embedded Workbench for several years and during 2017 they also tried the static analysis tool C-STAT.
Written by Kelsey Josund, Team Lead 2016-2017 at Stanford Solar Car Project
The Stanford Solar Car Project (SSCP) is a primarily undergraduate team of students who design, build, test, and race a solar-powered electric vehicle for entry in the World Solar Challenge. The team has been operating at Stanford since 1989.
Like all modern vehicles, solar cars have a number of PCBs running customized embedded code to sense their environment and control operations. SSCP designs and builds own boards each cycle with STM32F4 microprocessors and writes the code for them using FreeRTOS and our own custom libraries. The team has been using IAR Embedded Workbench for several years and during the last year also tried the static analysis tool C-STAT from IAR Systems.
SSCP consists of approximately 50 undergraduate students and a handful of master’s students. Most participants join partway through development of their first car and assist with construction and testing, then stay involved as a designer for their second cycle. The team consists of Mechanical, Electrical and Embedded code, Solar array, Aerodynamics, Battery, and Strategy sub teams. Team members work out of the Automotive Innovation Laboratory on Stanford campus, a space shared with autonomous vehicle research groups, a vehicle simulator, and a psychology/neurology of driving team.
SSCP enters the World Solar Challenge each time it is held, competing against student teams from around the world. The World Solar Challenge is an endurance race held in Australia in odd-numbered years. It engages student teams to race solar cars across the outback from Darwin in the north to Adelaide in the south, covering 3000 km of highway in less than a week. The race is held on a public highway that is not closed for the course, so we share the road with regular traffic. Most of the race is in very remote areas, but the first and last hundred kilometers or so are in urban areas. SSCP came in fourth in 2013 and sixth in 2015, only three hours behind the top team in a more than forty-hour race. In terms of speed per dollar spent, SSCP was by far the most efficient team in both of the last two races.
The electrical and embedded code teams consist of eight dedicated members and three senior leadership team members who help when required but also have other duties. Our team is more than 50 percent female and divided about equally between class years.
Our 2017 solar car, Sundae, has a completely overhauled electrical system relative to previous iterations. The system consists of a battery management system (BMS) and vehicle computer (VC) which we designed and programmed, maximum power point trackers (MPPTs) and a motor controller (MC) which we brought forward from previous cars, and small PCBs for the solar array wiring and head and brake lights. For comparison, in 2015 the car had four boards to handle the tasks now controlled by the vehicle computer, resulting in a much more modular but also more power-intensive and complex system.
Our production boards make use of the STM32F4 microcontrollers developed by STMicroelectronics. In addition, during development, we use ST’s discovery boards, which are microcontrollers with several built in hardware peripherals.
IAR Embedded Workbench provides support for a wide range of microprocessors (MCUs), and in particular supports the STM32F4 series of MCUs. In addition, ST has provided several demo projects specific for IAR Embedded Workbench, which have been useful for understanding the implementation and usage of protocols such as SPI and Ethernet. We have used IAR Embedded Workbench and STM32F4 MCUs in tandem for the previous three cycles and the current cycle.
We used IAR Embedded Workbench as the IDE for all embedded development. All team members who need it were able to download it and use it with the network license provided by IAR Systems and hosted locally in our shop. When on a test drive, we check out the network license for offline use. Hopefully, only very minimal code development will occur outside of the shop, but occasionally boards must be reflashed, pedals or motors recalibrated, or other minor fixes applied to the system.
IAR Embedded Workbench provides many useful features which team members use regularly. It provides a convenient interface for organizing files and libraries into groups. We organize our code into three different sections. The first main group is third-party embedded libraries, which include FreeRTOS operating system, FreeRTOS+TCP, FatFs, and Nanopb. The second main group consists of our inhouse developed libraries and drivers. These drivers aim to simplify the usage of components such as SPI (Serial Peripheral Interface), CAN, and ethernet. Finally, the third main group consists of board-specific logic, such as that related to battery management or driver controls.
IAR Embedded Workbench also has several features which are convenient for compilation and debugging. It is easy to specify which external libraries to use within our boards, such as switching the projects to a more recent version of FreeRTOS. In addition, IAR Embedded Workbench provides several facilities for simulating code and debugging and works well with FreeRTOS, giving us the ability to examine the operation of different running tasks.
The Motor Industry Software Reliability Association (MISRA) publishes an extensive set of code best practices and standards which can be enforced with a static analyzer. These help detect “dead” (unreachable) code, sources of potential bugs such as unused variables (which may indicate a typo or incomplete function), inconsistent function returns, and many other problems. It aims to facilitate code safety, security, portability and reliability in the context of embedded systems. All of these would be detectable by a human with sufficient inspection, but a static analyzer can detect them upon compilation much more quickly and reliably.
Since the solar car, like all cars, is a safety-critical undertaking, we aim to maximize the precaution taken in our approach to all aspects of our design. Mechanical components are designed with a high factor of safety, the aerodynamics are analyzed for cross wind performance, and the constructed vehicle is tested extensively at low speeds before progressing to highway speeds. For high voltage battery controls, both hardware and software checks are enacted to avoid danger to the driver. The code system is further designed to be modular and easy to debug and test such that we can be confident in its performance. Checks for MISRA compliance in our firmware are useful to detect potential sources of error, and IAR Systems’ C-STAT tool allows us to quickly and easily analyze our codebase.
After basic functionality was completed in our code in June 2017, we ran C-STAT across the entire system to identify potential problems. We were gratified to discover that with only minimal modification we were able to bring our team-written code into full compliance with MISRA C standards.
For the 2017 World Solar Challenge race, we completely re-engineered our electrical and embedded code system, necessitating a more thorough analysis of our code base to identify and correct potential and actual errors. Although it does not guard against higher-level logic errors, MISRA C-checking static analysis tools like IAR Systems’ C-STAT helps us create a safe code system for operation.
Images from the 2017 World Solar Challenge race: