The problems unique to distributed Model-Based Design arise from a few sources.
The engineers involved are not in continuous communication.
A typical engineering team is co-located, meaning the engineers enjoy informal face-to-face communication as part of their daily routine. This means issues are identified and resolved early as a natural part of the development process.
When coordinating subsystem models from different teams, the communication will be intermittent, and will often be more formal. This means coordination between the groups is more difficult and time consuming. This means errors and issues might be identified late in the development, making them difficult to resolve.
The different teams have different goals.
Whether they are different groups within a large company, or different companies, the teams involved in a distributed Model-Based Design project naturally have different needs. After all, they were segregated into different groups for a reason.
In most cases, these different goals are simply a matter of different focus. For example, an engine supplier will be focused on the engine, and might have little interest in the hydraulics subsystems. Such differences are typically resolved by simply communicating the project goals to all teams, and then working with them to align their goals with your project’s goals.
Sometimes, the different goals are incompatible with each other. For example, the controls engineers might want a sophisticated control loop, but the reliability engineers might insist on a simple, robust design. This type of conflict occurs in virtually every model-based engineering design project (this is also why you’re paid the big bucks!). In these situations, as project lead you must organize and balance the competing needs to find an optimal solution.
Addressing this up front at the beginning of the project is necessary, but it is never adequate. As the project evolves, the subsystem groups will discover new and possibly competing requirements that must be folded into the overall project. You must have a mechanism to resolve these differences quickly and at the proper point in your processes and procedures.
The different teams might not be as cooperative as you might need.
Sometimes the differences between the teams is non-technical, and can be political. In these situations, you need clear-cut mechanisms to objectively resolve differences.