Video Slides SIRI Slides ISAE Supaero
Student engineering teams face many of the same challenges as industrial organizations: complex systems, multidisciplinary collaboration, demanding schedules, limited budgets, and frequent team turnover. These difficulties are amplified when participants have little prior systems engineering experience and must develop both the product and the working methods at the same time.
This webinar presented two student rover initiatives that adopted Capella and the Arcadia methodology to improve reliability, clarify interfaces, and preserve knowledge. The first project supported a rover-and-drone team preparing for the European Rover Challenge. The second described the Sydney Interplanetary Rover Initiative, which develops a modular rover for lunar and Martian competitions.
Both teams demonstrated that a lightweight MBSE approach can provide significant value without requiring a complete or highly sophisticated modeling environment from the outset.
The European Rover Challenge project involved a rover and drone operating together in a simulated Martian environment. The system had to perform navigation, mapping, manipulation, drilling, sample collection, and scientific analysis within a short development cycle.
The initial document-based approach relied on spreadsheets, presentations, and separate technical files. This made it difficult to understand responsibilities, interfaces, and the rationale behind previous decisions. Reliability problems emerged not from isolated component failures, but from unclear assumptions, missing exchanges, and poorly defined test procedures.
Capella was introduced as a pilot to determine whether a lightweight MBSE workflow could reveal these issues earlier. The team focused on the four main Arcadia layers rather than attempting to use every available feature.
Operational Analysis translated the competition rulebook into actors, mission outcomes, and operational interactions. System Analysis then converted these needs into system functions, ensuring that each function could be traced to a mission objective. Logical Architecture exposed data, control, and subsystem interfaces, while Physical Architecture mapped these functions to real hardware, including power and communication paths.
The resulting model supported faster design discussions, earlier identification of hardware gaps, and more effective onboarding. Instead of reviewing multiple documents, students could explore one visual representation of the complete system.
The Sydney Interplanetary Rover Initiative adopted MBSE to manage a team of approximately 50 students developing a modular rover for the Australian Rover Challenge and other competitions.
The presentation focused on the post-landing mission, during which the rover must exit a lander, perform health checks, establish communication, operate controls, and map its environment.
The first modeling iterations highlighted several common beginner mistakes. Operational Analysis initially included activities that did not contribute directly to rover design. System Analysis mixed scenarios with functions and duplicated functions across several chains. Logical components were also confused with actors.
By iterating through the model, the team simplified the Operational Analysis, decomposed complex scenarios into atomic system functions, eliminated duplication, and clarified subsystem responsibilities.
Logical Architecture proved particularly useful because it made dependencies between subsystem teams visible. Functional chains exposed missing functions before integration, while Physical Architecture connected system behavior to actual components and physical interfaces.
The team also explored Modes and States Machines and Exchange Scenario diagrams. Exchange Scenarios became especially valuable because they represented the chronological interaction between subsystems. They helped the team analyze startup sequences, power consumption, command handling, communication failures, and timeout behavior before implementation.
In both projects, “lightweight” meant limiting the initial scope to the elements that provided immediate value. The teams prioritized operational needs, functions, components, interfaces, and traceability rather than attempting to implement a complete MBSE process from the beginning.
This approach was particularly suitable for student organizations, where members work voluntarily, experience varies considerably, and knowledge is frequently lost when students graduate.
The main lesson was that the tool alone does not guarantee adoption. Successful implementation also requires mentoring, early training, dedicated systems engineering responsibilities, and reusable modeling templates.
Q&A Highlights