The decision to adopt a new process can be viewed from two directions, what drives and what prevents companies from embracing new methodologies. In last weeks post we looked at the driving factors, this week we will talk about the preventive factors.
Core preventive factors
The motivation behind preventive factors are easy to understand; staying with the status quo is free of immediate risk. At first glance it facilitates project planning based on known development costs. However time and labor estimates are only accurate in situations of incremental change, such going from version 10.3 to version 10.4 of a stand-alone electronic throttle controller (a 20+ year old technology, with minor software updates) However that is rarely the case. The growing complexity of software systems exacerbates the problem of time and labor estimates.
Additional preventive factors
The previous product development risk is the factor most often given by managers; on the other hand, the technical staff (controls and systems engineers) consider the following issues.
- Loss of code efficiency
- Lack of ability to customize
- Concern about interfacing with existing code
- Need to train on new tools
- Not accepted for safety critical workflows
How Model-Based Design addresses these factors
In my previous post, Model-Base Design Driving Factors, the issues around increasing complexity, decreasing cycle time and the drive for cost reduction. In today’s post we will look at the engineers’ concern. First the loss of code efficiency.
Code efficiency: Code efficiency referees to the memory usage (RAM / ROM) and the execution speed (FLOPS) required to execute a given algorithm. Currently, automatic code generators do not produce code for single functions that is equal to the best C/C++ programmers. However, they produce better code than the average C/C++ programmer(1) and, for large systems, can find optimizations that humans may overlook. Further, any time a controls engineer spends becoming a better C programmer is time they are not spending becoming a better controls engineer.
In future sections of this blog, we will examine which areas are best developed using automated code generation tools and which should be done using hand coded methodologies.
Lack of ability to customize: Modern code generation tools provide users with the ability to fully customize the
- Function interface
- Data scope / data type
- Function partitioning
- Execution rates
- Code formatting
What is more, once the customization has been defined the tool will consistently follow the pattern, unlike human programmers who are can easily make formatting and functional mistakes.
Ability to interface with existing code: When transitioning to a model centered workflow there will be existing C code that will be used the difficulty in continuing to use these functions is dependent on 4 primary factors
- Is the function well partitioned?
- Is the function intended behavior well defined?
- Is the code well documented?
- Are there test cases for the function?
As you may have summarized the ability integrate existing code into a Model-Based Design workflow is similar to the ability to reuse functionality between projects. With modern Model-Based Design, tools allow users to easily integrate code assuming that the code is well partitioned.
Training on new tools: From a strict interpretation this critique is valid, however, it assumes a workforce that is already fully trained on existing C-based design workflows. As this link shows, C is no longer the most common starting programming language. Further, unlike model centered designs, does not directly map onto the engineering notation used by controls engineers. With this in mind understanding training can be viewed as a one-time additional cost.
Next week’s blog
In next week’s blog I will examine a typical timeline for adopting Model-Based Design addresses within a group and across your organization.
I think that one of the important preventing factors is “Cost”
Mathworks products including code generation products have a relatively high cost that prevents decision makers from deploying Model Based Design
Amjad,
While there is a price to MathWorks products there are multiple articles out there that demonstrate the return on investment (ROI) for adopting Model-Based Design tools.
https://www.mathworks.com/videos/measuring-return-on-investment-of-model-based-design-94248.html
https://www.mathworks.com/content/dam/mathworks/mathworks-dot-com/solutions/model-based-design/mbd-roi-video/Measuring_ROI_of_MBD.pdf
There are several factors to consider as to why MBD can make for a less costly development process.
First, there is the ability to detect design errors earlier in the development process through simulation.
Second, there is a lower level (or no) “hand off errors” when a single model is used at all stages in the development process.
Third, there is a clarity of communication that exists with diagram models over C code.
There are also costs associated with “free” software that are often not disccussed. These include, lack of documentation and support. Bugs with out resolution; lack of integration in to larger tool chains.