Model-Based Design projects typically evolve from simple to complex. They might start as a proof-of-concept or a feasibility study, and evolve into a sophisticated simulation with enough fidelity to answer detailed engineering questions. This churn is typical, and it involves adding new models, removing obsolete models, updating models that are already in place, and experimenting with different engineering concepts.
For a team that is co-located within a single office, the daily routine interaction between the engineers tends to keep this churn manageable, because everybody is aware of the project details and direction.
For a distributed team, this churn can be very challenging, for several reasons:
-
- Communicating the needed changes is difficult. This is discussed in my earlier blog, What are the Problems with Distributed Model-Based Design? This problem is usually addressed with ICDs, but textual ICDs can be ambiguous, making it difficult for the groups building subsystem models to follow them.
- Often, the project is a priority only for the group sponsoring it. The groups providing subsystem models might have a different set of priorities, meaning they might not deliver their contribution as quickly as you would like. You do not want to shut down the entire team while waiting for a single updated subsystem model.
- When a new model is delivered, you need a process to introduce it to the system quickly and cleanly. Without such a process, it will be necessary to halt development while the simulation is updated to include the new model. Sometimes this might be a quick process, but my experience has shown that it can also take weeks.