It’s hard to see the work that goes into something like an ASIC chip, especially when a large bulk of the work is software. At last count 186,265 lines of code had been written for 4 platforms but that number changes rapidly on a daily basis!
We asked one of our software engineers to help us understand a little more about what they do with the simple question – How do you monitor the voltage of a cell?
The simplest of statements or questions leads to the design and development of complex hardware and software systems. With the question posed of, “How do you monitor the voltage of a cell?” it all begins with a simple requirement:
“The system shall maintain cell voltage within a safe operating range”.
But what does that really mean?
Breaking Down The Requirement
Let’s start with “cell voltage”. We must know what the cell voltage is in order to maintain it, so we need to be able to measure it. This gives us a new requirement, “The system shall measure cell voltage”.
Next, what is meant by “operating range”? It suggests that the cell voltage has some limits that should not be exceeded. From our knowledge of Lithium Ion cells, we know that there is more than one chemistry, each slightly different from the others, each with its own upper and lower voltage limits. This means that we need to know the chemistry of the cell we are monitoring, so we can apply the appropriate limits. We now have a second requirement: “The cell chemistry shall be given to the system”.
One more word stands out – “safe”. Lithium Ion cells can be dangerous if not supervised, a task which is usually done by a separate piece of electronics known as a Battery Management System (BMS). It is the job of the BMS to make the system safe when a fault occurs. To do this, any unsafe operating conditions would need to be reported to the BMS. This now defines a third requirement: “The system shall be able to report a fault to the Battery Management System (BMS)”.
And the list could go on and on. This whole process of analysis and requirements decomposition is an important part of developing a safe application as per the automotive industry’s ISO26262 development process. It is known as “Requirement Management“.
For now, in order to simplify things a bit for this post, let’s just dive into the cell voltage monitoring aspect of the problem. For that to happen, the cell needs to be connected to some device able to react to different voltage levels.
“Connected” is the important word here, and, again, a new requirement emerges: “The system shall be able to monitor the connections to the terminals and react to a faulty connection”.
System Engineering
Now, it is time for the device doing the actual measurement to be defined. In our case, a Shmitt trigger circuit or an Analogue to Digital Converter (ADC) with some post-processing capability comes to mind. At this stage, a design decision needs to be made: “an ADC connected to an ARM processor shall be used to measure the cell voltage and compare it to predefined limits”.
These steps, taking the requirements and designing a system that fulfil them is usually referred to as “System Engineering“.
With the software specification written based on the above defined requirements, and the basic hardware to perform our measurements defined, we can now dig into the firmware configuration a bit more.
The ARM setup would take days to talk about, so I will just refer you to the extensive ARM documentation if you are interested in any of the details.
The ADC configuration, on the other hand, is a bit more manageable and can be discussed here.
- The ADC supplies need to be enabled and turned on internally.
- The timing must be defined: parameters like sample time, hold time, sample clock frequency, and more.
- The analogue input gain has to be defined according to the ADC reference used. This will allow us to make sense of the digital output of the ADC (what does the ADC value 1543 mean in Volts).
- Define a compromise between the frequency of the measurements and their accuracy as well as a filtering scheme for the output codes: in essence, the more measurements are averaged, the longer it takes and the higher is its accuracy.
- Finally, the ADC calibration strategy needs to be determined: the systematic offset and gain of the ADC input, as well as its predictable temperature behaviour have to be compensated for.
Once the ADC configuration is defined, it is time to add the measurements to the micro-controller firmware code.
Since there are many measurement channels in a real system, the measurements from the ADC need to be scheduled. This is the sequence that defines which external input is connected to the ADC at which time, and when it is triggered (i.e. when the conversion is started). It must then be filtered, calibrated and stored in the memory for further processing as a cell voltage value. This cell voltage value, held in memory, can then be checked against the cell chemistry limits also stored in memory. This will allow a status report to be sent to the BMS with the measured voltage and any fault condition that has been identified (the BMS will then decide what to do about it, but this is a different topic all together!)
Looking at all the aspects of the design and how it all fit together can be documented in a detailed software architecture.
The software architecture and specification are now defined well enough for the firmware to be implemented.
At this stage, I should mention another step that is still missing. A method to validate and verify that the requirements are met needs to be defined. This is part of the automotive ISO26262 test, verification and requirements managements, which shall not be discussed here.
In order to write code that is conform to best practices, easy to read and maintain, there are many constraints that need to be satisfied. To just mention a few: the firmware needs comply with the SafeRTOS programming guidelines (task based, …), it needs to satisfy MISRA C 2012 coding standards, it needs to satisfy our own coding standards, etc.
This briefly shows an example of the way to get from a general requirement to something that can be designed, for both hardware and software.
It is in no way an exhaustive analysis of the problem, many aspects have not been talked about and, even for the topics we have touched upon, drastic simplification have been made to make it more digestible!
