Tag: #adoption

Why choose Model-Based Design?

Published on by Michael BurkeLeave a comment

Over the last 18 years, I’ve had a variation on this conversation on every project I have worked on. (Dramatized for a blog audience)

  • Talented Engineer (TE): This model based stuff is interesting and all, but I can write the same code in 1/2 the time and it is 10% more efficient.
  • Me (also a talented engineer): That is probably true, you write very good code. Do you enjoy writing code?

  • TE: Well no, I write code because that is what I need to do to implement my algorithm. But wait, you are admitting my code is better?
  • ME: Yes, yours is. How many other people in your group are as proficient in C? And if you don’t enjoy writing code, do you enjoy designing <MAGICAL SPACE WIDGETS>(1)?
  • TE: I Went to school so I could work on MSWs(2), I love working at MSW Co on them; and really, maybe one out of the 20 can program as well as I do.
  • ME: Ok, well, how much time do you spend coding versus designing? Debugging versus testing?
  • TE: Tell me more about MBD stuff…

Realizing the benefit

The definition of Model-Based Design that I use is simple:

The use of a model(3) that is the single source of truth to 
execute two or more tasks in the design cycle

I work for The MathWorks, but, for a minute I will be agnostic. The definition simply says “a model.” The “model” can be a physical prototype, an analog computer, C code or, I hope, a Simulink or Simscape model. The important part is that the same model, without changes (4), is used at multiple points in the design cycle.

By my estimate I have drawn the V diagrams 1.3e5 times.(5)

If we think back to our TE in the opening section, what did they want to do? They wanted to design MSWs. They did not want to spend time creating test harness, writing test vectors, generating reports, and integrating with hardware. And why should they? TE was hired because he studied MSW and knows how to design the best MSWs; why take him away from that task? Since MBD allows users to use the same model at multiple points means that when our TE in design is done he can hand it off to another TE in the testing group who when they finish it can hand it off to a TE in integration who hands it off to a TE in release engineering. And why is this possible? Because it is much easier to find talented engineers who cover a given area very well (e.g. just test, or just release) than it is to find the magical unicorn(6) who can do all of the tasks well.

But wait! I can do all that in X

At some point down the line our TE comes back and says

  • TE: wait, just two paragraphs ago you said a Model could be C code, why should I use this graphical language?
  • ME: Wait! I just wrote that, so how did you see that? But OK, depending on your application, you may use Simulink, Stateflow or the MATLAB (textual) environment. The key is the infrastructure built up around the environment that enables the “more than one uses of the model.”

Can and should are two different beasts(7). Modern graphical modeling languages have supporting tools directly integrated into their environment. The set-up and integration is reasonably straightforward. Textual language, by their open nature, often have higher set-up and integration costs.

Making the transition / learning your way around

At first the transition to a graphical development environment (8) can seem daunting; Simulink’s base pallet has over 200 blocks(9), and knowing at first which one is the correct one to use can be confusing. However, like learning any other language you will quickly pick up the basics once you throw yourself in. Unlike learning a new programming language there are multiple transformation technologies you can apply directly to the model. When you start adopting Model-Based Design you should determine what “second task to execute” you want to adopt first. For more insights on this I would recommend viewing this roadmap.

Putting it all together

Ultimately the adoption of model based design isn’t about the tools, it is about the process. How you use each tool at each step along the way to the best effect. I welcome you to continue to join me in this space as upcoming blog posts delve more into Model-Based Design processes.

Ah the splash page image!

Model-Based Design for the VP/CTO

In past blogs I have written and talked about the Return On Investment (ROI) for adopting Model-Based Design. This link, from The MathWorks, provides another good overview on the ROI question. I want to propose another reason for this migration / adoption. Finding an engineer / scientist who knows how to develop “magical space widgets” takes time; on-boarding them them takes time. Losing them happens from frustration and boredom. This is one of the “hidden” drivers of ROI for MBD; when your people spend most of their time working on the things that interest them in ways that use their abilities and knowledge you have highly engaged employees which leads to greater innovation and higher quality.

Footnotes

  1. MAGICAL SPACE WIDGETS is a generic term for a customer project. Sometimes it is a car or a plane, or sometimes an actual spacecraft.
  2. MSW Is the agreed upon TLA for Magical Space Widgets.
  3. In the actual MBD workflow it will be multiple models, but let’s start simply
  4. Without changes is a simplification. The model you start off with at the start of the design cycle will be elaborated as it is developed. The important point is that if you took that elaborated model back to the earlier stages of the process it should still function in that stage (at a higher level)
  5. The version that I like best of the V diagram reflects the iterative nature of design, that within each stage there are iterations moving forward and back. Much like a PID controller, a good process is self correcting to errors in the process.
  6. Magical unicorns do exist, just don’t count on your process depending on them.
  7. Or in the image’s case, T-Rex
  8. OK, I’m not trying to be subtle here; once you start seeing them as development environments where you don’t throw away your work at each step along the way, the benefits become clear.
  9. Honestly I’m not sure how to count the number of “basic” functions in a textual language like C; while those 200+ blocks at first may seem like a lot, but once you realize they are targeted at the design of models you quickly pick them up.

Assessing your current state

Published on by Michael Burke2 Comments

During the exploration phase of adoption, the adoption team should have become familiar with the fundamentals of Model-Based Design e.g. model architecture, data dictionaries, testing, formal methods, report generation and so on. In that this blog is focused on groups adopting MBD it is a fair assumption that the current state is “introductory” (1) however the following sections can be used to identify where additional support is needed.(2)

Architecture

The following tasks should be understood…

shellmodelint

  • Encapsulation of models:  How to define each model in a format with defined interfaces and data.
  • Integration of models: How to integrate individual models into a larger integration model
  • Integration of existing code artifacts: How to integrate artifacts from the models into existing code artifacts and/or integrate code artifacts into the models

Data management

The following tasks should be understood…

boxbarimage5.jpg

  • Creation of data artifacts for use in the model: How to create data that the model can reference
  • Management of data artifacts: How to store and reference data artifacts in a scalable way.
  • Harmonizing data between model and existing code artifacts: How to reuse data between models and existing code artifacts

Testing

The following tasks should be understood…
exampleHarness

  • Creation of test harnesses: How to create a test harness that will exercise the model in a “stand alone” method.
  • Creation of data: How to create the data used by the test harness both for input and output evaluation.
  • Creation of test evaluation methods: Creation of methods for evaluating the outputs from tests

Supporting tools

The following tasks should be understood…

supportingTools

  • Basic use of version control: The users should understand which files need to be placed under version control.

Final thoughts

The obvious question arises “how do I move from “introductory” to “ready?”  There are three primary methods

  1. Training: There are multiple training courses (industry) out there allowing you to learn about Model-Based Design (university).
  2. Papers: Both academic and industry papers exist to help you learn about MBD.
  3. Outside help:  Outside help can come from either hiring people with MBD experience or hiring outside consultants.
  4. All of the above…

Footnotes

(1) Having an introductory level of knowledge of Model-Based Design methodologies is not the same thing as an introductory level of knowledge of software development.  Most groups that adopt MBD have a strong software development background.
(2) Most of the “Why is my state so [XXX]” I understand.  However, I don’t know why Pennsilvina and Connecticut got “haunted” as their “Why.”

Selecting the initial project

Published on by Michael Burke1 Comment

When setting the scope of the initial project it is critical to remember the objectives of the initial phase as outlined in earlier posts.  They are:

  1. Understand how artifacts from models integrate with existing artifacts
  2. Establish baseline testing activities
  3. Implement version control for new modeling artifacts
  4. Identify initial model and data architecture

The motivation behind these objectives is to determine how the models fit into your overall process.  To do this a system of appropriate complexity needs to be selected.

Integration

Within the software community the term “spaghetti code”(1) is used to describe software that is poorly partitioned lacking in well-defined interfaces.  puzzleAs the name implies integration with spaghetti code is difficult to break apart and difficult to integrate in a “clean” fashion.

For the first project a section of code should be selected with a reasonably clean interface.  The primary thing to avoid is a section of code that is heavily dependent on global data.  For the initial system, you are almost always integrating the new component into the existing system.  You should target components with a limited number of I/O and no or limited dependence on global data.

(Note: this section has assumed that you are working on a project with existing code that must be integrated with.)

Questions to ask

Will the model need to…

  1. call existing supporting functions?
  2. access global data?
  3. have context dependent execution?

The objective is to select a model that minimizes those requirements.

V&V

The verification(2) and validation tasks(3) play a key part in determining the scope of the initial project.  A good module would include

  1. Modal systems:  State charts with event based logic; allows for verification of context based execution.
  2. Conditional execution: If/then/else logic and enabled / disabled subsystems; allows for testing of model coverage
  3. Dynamic systems: Requires closed loop simulation with stimulus; validates the response characteristics of the system.

11519783-vector-check-marks-stock-vector-check-box-tick

For each of these three items the expected outcome should be fairly well know; the objective is not to find major errors, though this sometimes happens during initial projects, but to understand how you will do these activities.

Questions to ask

Will the model…

  1. produce measurable outputs?
  2. have multiple modes of operation?
  3. have dynamic responses?

The objective is to select a model that maximizes these requirements.

Version control

While one of the objectives of the initial adoption is to understand the artifacts that will be placed under version control this objective has little impact on the setting of the scope of the system.  Version control will be covered in a later post.  For now you can read one of my earlier linked in blog posts on version control.

Model and data architecture

The selected component should enable you to validate your selected architecture as outlined in the model architecture and data sections of this blog.architecture

Questions to ask

Will the model need to have…

  1. parameterizable data calculations.
  2. a functional interface definition.
  3. conditional execution interfaces.

The objective is to select a model that maximizes these requirements.

Complexity

The final metric to consider is algorithmic complexity.  While Model-Based Design allows people to develop more complex algorithms, for the initial project an algorithm that is well understood should be selected.  The objective is to examine how models fit into your development workflow, not to validate the capabilities of the model(4).

Questions to ask

The algorithm should be

  1. an existing or extension of an existing algorithm
  2. part of the project that will first deploy the Model-Based Design process.

The objective is to select a model that maximizes these requirements.

Footnotes

(1) I prefer the term “mushroom code” as it better explains how this code comes about.  It is generally code that has grown on top of well written code but due to organic decay is now difficult to take apart.

(2) Verification is intended to check that a product meets a set of design specifications

(3) Validation is intended to ensure a product, that meets the operational needs of the user.

(4) The capabilities of the modeling environment should be assessed; however this is a separate task from developing your Model-Based Design workflow.

(5) The header image is a reference to the song from “The Sound of Music: Do-Re-Mi ” which provides the advice on where to start.

Initial Adoption: Leveraging existing processes

Published on by Michael BurkeLeave a comment

A common misconception around adopting Model-Based Design is the degree to which things are “new“.  For most software / engineering groups adopting Model-Based Design is an exercise that consists of three main activities

  1. Redefining the development workflow Model-Based Design allows you to perform multiple operations earlier in the development cycle than traditional C based development workflows.
  2. Refactoring existing processes: Model-Based Design allows automation of some development tasks and processes.
  3. Re-targeting process tools: The tools used by the existing processes will change to reflect the automation and simulation tools that Model-Based Design provides.

While Model-Based Design adds in additional processes; it has been my experience that customers have used 70% or more of their existing processes for items 1 and 2.  Further, the automation gain from MBD simplifies many of their existing processes.

Redefining the development workflow

Model-Based Design has been used in conjunction with multiple design workflows, most commonly I reference a “double V feedback” workflow.  Regardless of the development workflow that you follow the key development concept is the movement of simulation-based design and verification into the front end of development.

2017-02-02_8-27-41
Delta V’s(1)

One of the key arguments in favor of Model-Based Design is the ability to simulate models early in the development process to improve the design of the system through system analysis; or as we said back in my automotive days “models, not metal.”   

In the same way that earlybugs implementation of functional and system level design reduces development time the ability to test models early in the development process both reduces development time and improves the likelihood of detecting bugs early in the process.

Refactoring existing processes

Following the same principals from redefining the development workflow refactoring existing processes considers three things

  1. Is the existing process still required?
  2. Can the existing process be automated?
  3. Are there new processes requirements or opportunities?

Is the existing process still required

By moving to Model-Based Design there are some processes that are no longer required, due to automation within the tool.  For example in model-based design processes that include a code generation step a manual code review process are generally not required.

Can the existing process be automated

New methods for automating processes routinely are created; even without moving to a Model-Based Design workflow a yearly review of processes that could be automated is a good best practice.  MBD workflows tend to have high levels of automation due to their built-in integration with automation tools such as Jenkins (continuous integration) or Rational Doors (requirements management)(2).

Are there new processes requirements or opportunities

Transitioning to Model-Based Design workflow will introduce new process.  This happens for three primary reasons.  Firs, the movement to MBD was driven by out side standards and the standard (such as DO-178C) requires a process to be performed.  Second the transition allows for a new process that will improve the final product, such as design based simulation.  The final reason new processes are adopted is in support of the interface between existing and new project development tasks and objects.

Re-targeting tools used by processes

The tools used by the existing processes will change to reflect the  the automation and simulation tools that Model-Based Design provides.  This blog will goes into more detail in “The role of supporting tools in Model-Based Design” and “Model-Based Design Building Blocks” posts (3).

strategist-clipart-target

Footnotes

(1) In just a casual search I found over 50 graphical representations of the “software design V.”  As with all things make sure there is clarity around what you are talking.
(2) While both Doors and Jenkins are solid tools in their categories the selection of them is not an endorsement for that role.
(3) Currently these two sections are still a work in progress.  More detail will be filled in as this blog continues developing.

Initial adoption: objectives and metrics

Published on by Michael BurkeLeave a comment

Objectives and metrics

Based on the information collected from the process adoption team the objectives for the initial adoption phase should be set.  While the specifics for any given organization will be different the following outline is a standard view.

1403204517-3-keys-measure-success-loyalty-program

  1. Technical 
    1. Complete 1 or 2 “trial” models
      1. Identify the initial model architecture
      2. Identify the initial data architecture
      3. Establish baseline analysis methods
      4. Establish baseline testing methods
    2. Understand how artifacts from models integrate with existing artifacts
    3. Implement version control for new modeling artifacts
  2. Managerial
    1. Review methods for measuring model key performance indicators (KPIs)
    2. Review resources required during initial adoption phase

The technical metrics

Completion of the trial models

In a future post we will examine how to select your trial model,  but for now let’s answer the question “what does it mean to complete a trial model? ”  This decomposes into the four tasks as outlined above.  The model and data architecture are covered in some depth in previous posts so let us talk about analysis and testing.

Within the Simulink domain, a fundamental aspect of a model is the ability to simulate the behavior of the plant or the control algorithm. analog-simulationThe simulation is used during the early stage of development to analyze the model to determine if the functional behavior of the model.  The developer performs elaborates the model until the behavior functionality matches the requirements.  This is verified through simulation.  Once the model meets the requirements the functionality can be “locked down” through the use of formal tests; again using simulation.

It is worth noting that some requirements will be met before others, they should be formally locked down under test as they are achieved.

Integration with existing artifacts

For most companies, unless they are starting from
integratesoftwarea clean sheet there will be existing software components that need to be integrated with those created by the Model-Based Design process.  There are three types of integration

  1. bringing existing software into the Model-Based Design framework
  2. Bringing Model-Based Design artifacts into the existing architecture.
  3. A combination of 1 and 2.

The topic of integration will be covered in greater detail in an upcoming post.  However, the fundamental guidelines for integration (in either direction) are the following.

  • Create software objects with well-defined interfaces (encapsulation)
  • Limit dependencies of the software objects on external objects
  • Minimize the use of “glue code”(1).

Version control of objects

Version control processes use tools to enable team-based development while maintaining multiple “release” or “branches”.  During the initial phase of the project which software objects will be placed under control and how a “release” will be defined should defined.  This initial definition will be refined as the Model-Based Design process is elaborated.  This blog will go into detail on this in a future post.  The basic questions are

  • Do you include derived objects in the version control software: .c, .h, test reports…
  • How do you arbitrate check in conflicts: How do engineers resolve conflicts in their model interfaces?
  • How do you share data / models across projects: What methodology will facilitate reuse of objects across multiple projects with minimal configuration impact?

Managerial metrics

The initial adoption phase by its nature will be slower than later phases as people are still learning new capabilities and processes.  57572027-gears-and-kpi-key-performance-ind-cator-mechanismThe primary objectives during this phase are

  1. Learn what bottlenecks with the new process.
  2. Understand existing issues uncovered by the transition
  3. Determine level of resources for the next stage

The discovery of “Objective 2’s”, existing issues, often surprises people.  The act of transitioning to a new process forces the evaluation of existing processes and, more often than not, illuminates existing shortcomings.  Extra care should be taken to ensure that the new process addresses those shortcomings.

In the next stage, the validation project, the team should expand beyond the initial “core” team. Ideally, a people from outside the initial project scope should be brought in to identify developmental pain points that did not exist in the “core group” processes.

Footnotes

(1): “Glue code” is a software object created solely for the connection of two other software objects.

Adoption Time Line: Exploration Phase Part II

Published on by Michael Burke1 Comment

Continuing from an earlier post we now look at how you set the objectives for the initial adoption phase.

We need the champions

Before we proceed in setting objectives we need to talk about resources.  There are 3 resources that are required for an adoption process to succeed; they are

  1. Champions:  Technical and managerial support for the adoption process.  Without active advocates change will not happen.
  2. Time:  The champions need to have time allocated to working on the process change.  Ideally the technical champions will have 100% of their effort allocated to the adoption of the new process.  When the resources are allocated at less then 80% the change is likely to fail.
  3. Experience:  The people working on the project need to understand the current workflow so they can address its short comings and speak to the people outside of the adoption group.

An earlier blog post from LinkedIn provides additional details.

Setting goals

Based on the information collected from the process adoption team the objectives for the initial adoption phase should be set.  While the specifics for any given organization will be different the following outline is a fairly standard point

  1. Prior to start of initial adoption phase
    1. Allocate resources to the process adoption team in support of project
    2. Process adoption team completes identified required training
    3. Review reference materials to understand current industry best practices
  2. By completion  of initial adoption phase (1)
    1. Technical 
      1. Understand how artifacts from models integrate with existing artifacts
      2. Establish baseline testing activities
      3. Implement version control for new modeling artifacts
      4. Identify initial model and data architecture
    2. Managerial
      1. Review methods for measuring model key performance indicators (KPIs)
      2. Review resources required during initial adoption phase (2)

Bounding the problem

A word of caution; model-based design offers multiple tools and methods as part of the development workflow.  A common pitfall when establishing any new process is to “overreach” utilizing multiple new tools all at once, the resulting diluting of attention introduces errors of misunderstanding and results in a slower adoption of the process.  In the initial adoption phase posts, I will discuss the normal building blocks for Model-Based Design.

Next post

The next series of posts will cover model architecture and data management.  These topics will help in understanding the next phases of the adoption and establishment processes.

Footnotes

(1) The term “adoption” reflects the fact that there are existing resources to guide companies in adopting workflows.  I always encourage people to leverage existing information rather than creating new workflows from whole cloth.  This is critically important when working in a safety critical environment.
(2) Identifying the resources required for future phases should be based on the KPI information gathered from the initial adoption phase.  It should also take into account the “cost of learning” associated with starting a new process.

Adoption Time Line: Exploration Phase Part I

Published on by Michael Burke4 Comments

In our last post we reviewed the high level adoption time line; in this post, we will cover the exploration phase.  The objectives of the exploration phase are to

  • Understand the factors that influence the time required for adoption
    and
  • Set deliverable for the initial adoption phase.  (covered in part II)

From the last post, the factors influencing the adoption timeline are

  • Current usage of modeling tools:  The level of current knowledge and usage of modeling tools will influence the initial training and evaluation required.
  • Current software development processes:  The software processes adopted as part of a Model-Based Design workflow will leverage or extend many of your current software development processes.  The more formalized the existing processes the simpler the transition.
  • Compliance with high integrity software development processes: For a subset of software development projects compliance with high integrity processes such as the DO178-C or ISO 262622 imposes verification and traceability requirements that other processes can omit.
  • Processes required for development:  The Model-Based Design environment offers multiple tools for the development of software.  Determination of which tools and processes are required is done as part of the initial adoption phase.

The first step in exploration phase is to identify the stakeholders in the change process. and to understand the current development process both what works well and what needs improvement.  threeps

 

 

Role Deliverable
Controls Engineer Outlines current controls development workflow and roadblocks.
Software Engineer Outlines current software development process and method of integrating with the controls software
Project manager Outline current Key Performance Indicators (KPI)

Questions you should ask

  1. How do you currently connect requirements to
    1. Controls deliverable
    2. Testing
    3. Bug tracking
  2. What is your controls development process, waterfall, scrum,  design V?
  3. What are your current software tools
    1. Version control
    2. Bug tracking
    3. Test infrastructure
    4. Requirement tracking
  4. How is the software handed off between
    1. Controls and software engineers
    2. Controls and  test engineers
  5. What is your current testing process
  6. Where have most bugs entered into your current development process?

In the next post

In the next post, I will outline what questions you should ask moving forward.

Model-Based Design Adoption Time Line

Published on by Michael Burke4 Comments

This post starts a section looking at the timing and requirements of each phase of establishing a Model-Based Design culture.   With that in mind, the timeline for adopting an MBD process and establishing an MBD culture is dependent on multiple factors including, but not limited to

  • Current usage of modeling tools:  The level of current knowledge and usage of modeling tools will influence the initial training and evaluation required.
  • Current software development processes:  The software processes adopted as part of a Model-Based Design workflow will leverage or extend many of your current software development processes.  The more formalized the existing processes the simpler the transition.
  • Compliance with high integrity software development processes: For a subset of software development projects compliance with high integrity processes such as the DO178-C or ISO 262622 imposes verification and traceability requirements that other processes can omit.
  • Processes required for development:  The Model-Based Design environment offers multiple tools for the development of software.  Determination of which tools and processes are required is done as part of the initial adoption phase.

There are 5 phases of adoption and a 6 ongoing optimization phase.  The adoption and establishment can take between 3 to 5 years depending on scope as outlined above

  1. Exploration phase: 1 ~ 3 month
  2. Initial adoption: 3 ~ 6 months
  3. Validation project: 6 ~ 9 months
  4. Group roll out: 12 ~ 18 months
  5. Department roll out: 15 ~ 24 months
  6. Optimization: ….

In future posts, we will look at these phases in detail.

Model-Based Design: Preventing Factors

Published on by Michael Burke2 Comments

 

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

  1. Is the function well partitioned?
  2. Is the function intended behavior well defined?
  3. Is the code well documented?
  4. 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.