In an ideal world, requirements are clearly defined. You start on a fresh screen and develop something exciting and completely new, but as we all know, this is almost never the case.
When we implement new features in automotive software, either model based or hand coded, we always have to deal with legacy software. Everyone is afraid of touching existing software – “never touch a running system” also applies to automotive software. A common strategy is to add a decision point, leave the old software untouched as much as possible and implement a separate path for your new feature. Following this strategy for years resulted in where we are now – huge, much too complex software models where almost nobody can tell what the software is doing.
How did BOSCH solve complexity?
I am not giving away any secrets when I say this also holds true for Bosch, our parent company and the leading Tier One in the automotive industry. Maybe having huge complexity is even worse within a Tier One, because they have to support so many different vendors, variants and customers all over the globe.
Bosch started analyzing the complexity issue ten years ago within the corporate research department. The project name was SCODE, an acronym for System Co-Design. Co-design, as it tries to incorporate all aspects causing complexity in the software. This means not only functional requirements, but also requirements coming from calibration, hardware specifics or regional requirements. ETAS has been involved in this project from the very beginning, helped develop the method over years and is still the service provider for SCODE tooling and methodology inside Bosch. In 2017, ETAS started offering this approach to customers outside of Bosch in form of a new tool called ETAS SCODE-ANALYZER, together with related consulting services.
What does SCODE-ANALYZER do?
First of all, SCODE-ANALYZER does not read in any models, source code, requirements etc. It is a purely manual process involving subject-matter experts as well as SCODE methodology experts. I know that sounds scary and like a lot of work, but let me assure you, it is no extra work as you usually do all of this already in your current development process – the SCODE methodology just channels that work into a much more formal approach.
The result of a SCODE analysis is a 100% complete, consistent and deterministic definition of your system logic . Depending on the abstraction level SCODE methodology is applied to, the analysis result can either serve as a system analysis, specification for implementation, or even generate an implementation of a state-machine or logic block in either ASCET-DEVELOPER, c-code or MATLAB Simulink®.
How do we get these results?
The SCODE methodology is very flexible and can be applied to different levels of abstraction – so the “system” can be an actual system but also a function or implementation. Either way, SCODE leads you through a three steps approach to formalize the system knowledge and come up with the afore mentioned results. These steps are:
- Define the input and output space
- Define the modes of operation
- Define the transitions between modes
I know this is very abstract, so I will demonstrate with a little example.
Example
I am going to demonstrate the three-steps-approach with an example of a starter-generator control which might be used in that (or similar form) in some mild-hybrid implementations. The basic requirements to that system are
- Regenerate energy “whenever possible”
- Boost the engine “when required”
This is an example I made up based on SCODE workshops I conducted in the last years and not representing a real-world application or requirements. The main purpose here is to give you an idea of how SCODE methodology works.
Step One – defining input and output space
In this first step the subject matter experts (you, me, others…) have to define all inputs and outputs for the system. For the starter-generator control I define the following inputs important to my system: the battery’s state of charge, the vehicle speed and driver’s request. Then, I list these input dimensions in the tool. For simplicity and the sake of the example, I omit the output space here but outputs work the same way.
For each dimension, I need to provide the alternatives that can occur and are going to affect my control. You can think of them like equivalence classes in testing. In the example I choose the following:
Don’t be afraid of putting something wrong here. The SCODE methodology will always lead you back in case you missed a dimension or an alternative.
With the given input space, SCODE-ANALYZER already crunches some numbers in the background and tells me, that there are already 18 possible permutations of the input space I, as the controls engineer, have to take into consideration. Why 18?
Because there are 3 x 2 x 3 possible input alternatives. Of course 18 is not a realistic number for a real world project but this is just an example. And it is not really about the input space – I have seen SCODE projects with 400,000 or even more input combinations. What matters more is the number of system modes…
Step Two – defining modes of operation
From the requirements we can already tell, there are most likely two modes of operation, i.e. recuperation (or regeneration) and boost.
With the two given modes as a starting point, our task is to distribute / map each of the 18 different possible combinations to exactly one mode. This is done with the help of rules selecting sets of combinations – so you do not have to visit each combination individually. That would really be a nuisance for projects with higher numbers.
An example of such a rule is: battery state of charge is ‘okay’ or ‘fully charged’, the vehicle speed may be ‘standstill’ or ‘moving’ (we don’t care) and the driver’s request is ‘accelerate’. We map this combination to the boost mode and SCODE-ANALYZER tells us that this rule takes away 4 (2x2x1) of the 18.
Next, we look at the recuperation mode. We recuperate when the battery state of charge is not ‘full’, the vehicle is ‘moving’ and the driver’s request is ‘brake’ (see #1). SCODE-ANALYZER offers us a rule editor to easily create these rules (see #2). This rule takes away another 2 of the 18. In the tool we cannot only see how much combinations are already handled (see #3), we can also get suggestions which combinations haven’t been handled yet (see #4).
One of these suggestions is “What mode are we going to be in when the driver’s request is ‘none’?” Currently, we cannot map this clearly to neither boost nor recuperate. So the SCODE methodology led us to a third mode – the ‘neutral’ mode. The systematic approach of SCODE-ANALYZER forces us to visit all corner-cases and combinations and in this way also reveals all gaps in e.g. the requirement specification.
While mapping input combinations to modes, SCODE-ANALYZER continuously performs checks in the background and immediately informs us when there is an overlap between modes, i.e. when certain input combinations belong to more than one mode.
Once step two, also called static analysis, has been completed, SCODE-ANALYZER displays a decision tree for the modes. This is used to review what we captured in the different rules. Input dimensions are marked blue while modes are marked grey. Time for some dynamics…
Step Three – defining transitions between modes
In the third step, as you may have already guessed, our task is to define events for switching from one mode to another and even more importantly, which transitions we forbid with respect to events that do not occur. The events have to be defined on the input dimensions from step number one, also using the rule editor.
In our example I do not want to allow switching directly from boost to recuperate – the transitions should always go through the neutral mode. So I strike out these transitions. Then we have to define the different events e.g. for switching from neutral ‘to recuperate’. The rule for that is: we switch to recuperate when the battery is ‘not empty’, the vehicle is ‘moving’ and the driver’s request is ‘brake’.
This is the dynamic part of the analysis and SCODE-ANALYZER also performs various checks in the background such as: Is the event permitted in the target mode? Does the event not overlap with the start mode?
By this we ensure not to encounter any annoying behaviors as toggling state machines, deadlocks etc. and we can be 100% sure we’ve considered each and every possible combination and we’re also reacting on them accordingly.
And what is 100% sure? When you take a look at the screenshot a few lines above, you will notice there are some red fields in that transition matrix. When you click on them you will see:
:
There are some (8) uncovered states (=events) in the dynamic part for the boost mode we haven’t taken care of. One of them is “we’re in boosting and the battery’s SOC becomes empty”. This usually leads us to the neutral mode but in that very moment when it happens, we are boosting with an empty battery. Long story short: to resolve this we need to introduce a fourth alternative for the battery’s SOC called ‘critical’, which leads us out of the boost mode.
This then leads us back to step number one and increases the number of possible combinations to 4x2x3=24.
We’ll end the example here because at this point, we would have to revisit all steps again making sure we’ve considered all possible combinations, mapped them to modes, defined our mode transitions properly… you get the idea?
Conclusion
When you apply the SCODE methodology on your control logic and perform an analysis with SCODE-ANALYZER, you can be sure that the resulting logic is 100% deterministic and consistent and that you have considered all possible input combinations, which your system may be confronted with.
Adding new features becomes easy because, as soon as you add a new mode, dimension or transition, you immediately see the effects on your current implementation. SCODE-ANALYZER forces but also helps you to identify and solve any overlaps or clashes caused by the change. By this, new features are “weaved” into the existing implementation rather than adding another layer.
SCODE-ANALYZER forces you to consider even unlikely cases and reveals any requirement gaps during the design phase of your control logic, which in the best case, you would have found during testing…
In the end SCODE-ANALYZER delivers a model containing the complete system knowledge in a formalized form which can be used as specification for implementation or, if you’d like, automatically generate an implementation in MATLAB Simulink®, ETAS ASCET-DEVELOPER or c-code.
Any questions? Just comment below. If you want to see how the SCODE methodology is applied to one of your problems, please email us or contact me directly via LinkedIn. I am happy to demonstrate – the only thing we’ll need is some time (1/2 day) and one or more experts from your side.
