Wacky from WebEx: Better meetings with MBD

The following is a two week running average⁽¹⁾

1. Can you hear me? (8 times per day)
2. I can’t hear you! (4 times per day)
3. Hold on, let me restart that (3 times per day)
4. I love Video Calls (sarcastically: 5 times per day; honestly… still waiting)

The use of WebEx, Teams, or morose code is the central fact of life during the COVID shelter in place as is the general irked response to these meeting malfunctions. There are good general tips on Video Conference best practices. What they are all trying to address is how to make the most of an artificial interaction environment.⁽²⁾

The good news is that Model-Based Design offers a singularly powerful platform in which to collaborate.

What is new for MBD Webex meetings? What to do?

What then is different about meetings over WebEx and what makes it unique for Model-Based Design?

• Attention span is lower in Video Conference meetings: Homework is key
  • But by it’s nature MBD lends itself well to the generation of artifacts that support online reviews.
• Focus on the “item” is key: knowing what you want to share and how to best present it is critical
  • The graphical nature of models is simpler than text based languages for online reviews. When presenting validation results, graphs (i.e. plots with error bars) should be leveraged.

How to make it better with Model-Based Design

Ok, first off let’s say it…many people during meetings are following links instead of following the meeting. What can Model-Based Design do to support people “being there” and engaged during the meeting? Assuming you and your audience have done your homework⁽³⁾ then it becomes a question of “what types of things should I be reviewing and what do I need to present?”

These recommendations are useful for any design process. Note: underlined “Homework” are areas where the automation and simulation aspects of Model-Based Design greatly improve the process…

• Interfaces: when reviewing interfaces the ICD is your best friend
  • Objective(s):
    1. Sign off / agreement on the proposed interface
    2. Validation that the generated interface matches the agreed upon version
    3. Modification to an agreed upon interface
  • Homework:
    1. Document who produces and consumes the information
    2. Generated document of the realized and proposed ICD ⁽⁴⁾
    3. Again, document who produces and consumes the information as well as the impact on downstream modules.
• Requirements: For now assume that the requirements are written and you are performing validation steps.
  • Objective(s):
    1. Ensure that everyone understands the requirements in the same way
    2. Demonstrate that all of the requirements have been validated
    3. Hold an exception or modification meeting
    4. Demonstrate traceability of the requirement
  • Homework:
    1. Consider using the model to demonstrate the requirement
    2. Provide the test cases that demonstrate that the requirement has been met
    3. Provide the technical data that shows why the requirement cannot be met (this can be done through the use of closed loop simulation)
    4. Generate the report showing the full requirement’s traceability
• Standards: Conformance to standards allow for the easier communication
  • Objective(s):
    1. Validation of standards that require “engineering judgment”⁽⁵⁾
  • Homework:
    1. Provide the referenced guidelines as well as any commentary on the rationale for the guideline. In safety critical conditions, provide validation that the compliance adheres to safety standard requirements.
• Bugs: when you are trying to get to the root cause of an issue
  • Objective(s):
    1. Understand what is causing the problem and what the required outcome is
    2. Understand what is allowable under the requirements for the feature
  • Homework:
    1. Provide information on what has been tried to debug the issue (and be willing to revisit it)
    2. Provide simulation data that demonstrates the bug “in action”
    3. Isolate the bug to the “smallest” module possible

Foot notes

1. These statistics represent 2 ~ 4 meetings per day, 5 days a week. Everyone has said items 1 or 2 at least once.
2. In an average meeting much of the information is communicated informally through body language, side conversations and the ability of people to react to how everyone in the room is responding.
3. What is “meeting homework”? Three things:
   1. Define what you want to cover in the meeting; information to present and questions to be answered.
   2. Provide the audience with information beforehand so they can respond to your questions/presentation.
   3. Have supporting information ready to present during the meeting; it’s important to prevent the number 3 “let me restart that” more than once in a meeting.
4. There are multiple tools to generate the ICD document from a Simulink model; the comparison to the proposed interface can likewise be automated.
5. Engineering judgement isn’t about having an opinion, it is about knowing the impact of your decision if you are wrong.