MBSE Learning Journey Showcase 2026 Autumn
Special lectures by Prof. Hiroaki Takada and David Hetherington, with a talk by Kazuyuki Murakami and a dinner reception
Capturing the subject in the Abstract to give the implementation Freedom. A complex system expressed simply; simple enough to be understood, and understood well enough to be talked about. A day for taking in the thinking behind the MBSE methodology, how it is approached, and what it does for you, through talks and conversation with people who do this work for real. Companies taking part in the MBSE Learning Journey present cases from their own practice, and there is time to discuss them with all three speakers.
- Date
- Mon, Oct 26, 2026
- Time
- 9:20–18:10
- Venue
- YAMAHA MOTOR Regenerative Lab5-1-2 Minatomirai, Nishi-ku, Yokohama, Kanagawa
- Format
- On-site
- Hosted by
- Liberal Logic Inc.
- Language
- Japanese and English (consecutive interpretation)
- Registration closes
- by Fri, Oct 16, 2026
- Capacity
- Up to 100 seats(sign-up ends once capacity is reached)
Speakers Prof. Hiroaki Takada, David Hetherington, Kazuyuki Murakami
Fee General ¥8,800early-bird rate through Wed, Sep 30, 2026 General ¥13,200from Thu, Oct 1, 2026 Students ¥2,200
All prices include tax, lunch, refreshments and dinner at the reception.
What this edition is for
The MBSE methodology makes a complex problem simple enough to understand, and understandable enough for people to talk it through together: it lays what you might call the groundwork of engineering. Applying it takes waste and strain out of the development floor, and the communication and the value it opens up let you solve problems both effectively and efficiently. For all that it offers, there are few chances to meet the methodology in a form you can actually apply. You read the books, you try the tool, and you stop at the question of how any of it works in your own setting; more often than not, none of it ever reaches the development work itself. We hope this day lets you grasp what lies at the core of the MBSE methodology, and gives you a hint for putting it into practice where you actually develop.
Which MBSE methodology does this event work with?
Tim Weilkiens’ SYSMOD
MBSE is the general name for putting a model at the center of development; on its own it does not tell you how to proceed. What to think through, in what order, and what to decide: setting that out is what a methodology does. SYSMOD, the methodology this event works with, was set down by Tim Weilkiens, co-author of SysML v1 and v2, and it is the ground the MBSE Learning Journey treads week by week. Who does the work, what work it is, by what method. Because that much is settled, it can be used in real work.
Document-centric and model-centric approaches
Compare the process under an MBSE approach with the process under a document-centric approach. Analyse the problem, work out the requirements, put the architecture together. The activities and their order do not change. What changes is where and how the result is kept, and how it is put to use.
Compare the two examples below. In each, a set of textual requirements has been turned into a use case, that is, grouped. The WHAT is the same; only the HOW differs.
The process is the same either way, document or model. In the document, if what is written contradicts a requirement or the architecture, nothing tells you. In the model, what you put down is connected to everything else in the model, and that is what makes it checkable.
The MBSE methodology is not a matter of learning a new process. It is a matter of changing how you approach the work.
The MBSE methodology laid over a turtle diagram
The figure below is a turtle diagram, used in the field of quality management. The process sits in the middle, and around it go what enters it, what leaves it, who carries it out, what they use, how they proceed and what it is measured by. Between them they cover what managing a process calls for. Plenty of organizations, though, have never drawn even this one sheet.
Over the turtle diagram come the three pillars of MBSE (the modeling language, the modeling method and the modeling tool), and over those the MBSE methodology. Assembling the pillars on their own only adds tools. It is when the three pillars and the MBSE methodology engage with one another and work as a whole that a manageable picture of the whole comes together, one in which who does what and how, and what comes out of it, can be traced. Use the lever below the figure to feel the change stage by stage.
(Drag the lever left and right to watch the figure build up stage by stage.)
No tooling, and no agreement on how the work proceeds.
The tooling is in place. Who does what is still open.
The tooling is in place, and who does what, in what order, and what they produce is now settled.
Who it is for
People in the manufacturing industry doing real development work
- Interested in an MBSE methodology
- Have already touched MBSE at work but have felt nothing come of it
- Have not been able to turn the problems in front of them into concrete improvement
People in the manufacturing industry responsible for development processes and competence management
- Process owners (ISO 9001 / IATF 16949)
- Engineering process improvement teams
- Leaders responsible for competence management
- Assessors who carry out assessments and propose improvements
University students who intend to work in development in the manufacturing industry
- Mechanical engineering, mechanical systems engineering, intelligent mechanical engineering, precision engineering
- Mechatronics, robotics
- Electrical engineering, electronic engineering, electrical and electronic engineering
- Electronic and information engineering, information engineering, information and communication engineering
- Control engineering, systems and control engineering, systems design engineering, aerospace engineering
Who we have in mind, and why attendance is limited, is set out in About the Showcase. For the conditions of taking part, see Taking part further down this page.
Speakers
How do you build a complex system? Three people who have looked at that question from the history of the field, from outside the country, and from inside an organization. The spine of the day is Kazuyuki Murakami’s two-part talk, 3 hours 40 minutes in all, with the special lectures by Prof. Hiroaki Takada and David Hetherington set around it.
Prof. Hiroaki Takada
Professor, Global Research Institute for Mobility in Society, Nagoya University
Ph.D. (Science), the University of Tokyo, 1996. After posts at the University of Tokyo and Toyohashi University of Technology, he has been a professor at Nagoya University since 2003, and directs the Center for Embedded Computing Systems in its Graduate School of Informatics. He works on embedded systems, real-time operating systems, automotive control systems and networks, functional safety and security among other fields, and leads TOPPERS, a project developing real-time operating systems for embedded systems. Fellow of the Information Processing Society of Japan and of the Japan Society for Software Science and Technology, whose president he was from 2022 to 2025.
David Hetherington
President and founder, Asatte Press, Inc.
After a spell as a system architect at IBM Engineering Services and as a site manager at Wind River, he founded Asatte Press, Inc. in Austin, Texas in 2011: an independent publishing and consulting company working where systems engineering, safety, security and multilingual technical communication meet. From 2019 to 2026 he was a principal at System Strategy, Inc., helping semiconductor, aerospace and automotive companies shape their MBSE strategy, tool selection and modeling processes. He now leads the rewrite of SAE J3187-3, the recommended practices for applying MBSE to System-Theoretic Process Analysis (STPA), and is a key contributor to the forthcoming J3187-4 on applying STPA to system security. He takes part in the INCOSE Automotive and Configuration Management working groups and lectures internationally on MBSE, STPA, system safety and security. Lately he has been working on the use of AI to build SysML v2 models out of unstructured stakeholder input. He speaks and reads Japanese well. He also takes a strong interest in developing people, and has spent years helping young Japanese, Korean and Chinese engineers build the ability to present and discuss their work in English in a professional setting.
Kazuyuki Murakami
Senior Lead Engineer, Product Safety and Security, Gentex Japan, Inc.
From 1999 to 2017 he was at Alps Electric, working on functional safety management and engineering for road vehicles and leading a software development group; from 2007 to 2011 he was a line manager for application engineering at ALPS Electric Europe in Munich. There a counterpart at a European OEM put it to him: “Murakami-san, you are not doing SE. No, wait. Not one Japanese company is doing it.” The remark settled him on making systems engineering his life’s work. In the course of that work he came up against the limits of a document-centric approach and set out on the shift to MBSE. Around that time he began visiting Tim Weilkiens in Germany to learn the MBSE methodology at its source. By way of Autoliv he moved to Veoneer, where he went from systems and functional safety engineer to line manager for functional safety, cybersecurity and SOTIF, and then to MBSE methodologist and practitioner, taking on the job of making MBSE stick across the organization. From 2022 to 2024 he was a manager for ADAS function and algorithm development at ZF Group, and he has held his present post since 2024. He is an INCOSE ASEP and an OMG Certified Systems Modeling Professional (OCSMP Model User and Model Builder - Fundamental), and is listed on the OMG SysML Wall of Fame. He facilitates the MBSE Learning Journey and gives Lectures I and II on the day.
Prof. Hiroaki Takada ― where embedded systems development in Japan came from. A leading figure who has followed the embedded field over a long span, across domains from automotive to rockets. Few people can account for how the way we develop today came to be the way it is. Having watched a great many real projects at close range, a researcher at the front of the field is placed to say something worth hearing about where development in Japan has been and where it ought to go.
David Hetherington ― how Japanese practice looks from the outside. He has seen systems engineering in both Japan and the United States and knows the cultural ground on both sides. His connections reach past those two countries into Southeast Asia and Europe, and he brings back what he learns there. Where MBSE meets functional safety and security, he leads the revision of the international standard SAE J3187-3.
Kazuyuki Murakami ― how MBSE actually takes root inside an organization. He has spent years as a systems engineer in the automotive industry doing systems engineering with MBSE, and has carried its adoption inside organizations as both methodologist and practitioner. He holds INCOSE ASEP and is a close associate of Tim Weilkiens, co-author of SysML v1 and v2. What he covers is the route itself, bringing the grounds for every decision across the life cycle as ISO/IEC/IEEE 15288 sets it out, from concept through retirement, into a single model whose consistency can be checked, together with how the judgment calls are made: the part that books and tool documentation leave out.
- Questions from your own work: We have set aside 50 minutes for discussion and questions with all three speakers together. You can put them directly to the three speakers.
- Practitioners working on the same problems: Over lunch, refreshments and the reception, you can hear where other companies’ development floors got stuck, and how they worked their way through it.
The shape of the day follows those three vantage points. Murakami’s first talk takes you into the route the methodology lays out; Hetherington’s special lecture widens the view to the world beyond; Takada’s special lecture adds a sharp reading of how things get made in Japan. After the three of them discuss it together, Murakami’s second talk returns to the concrete work.
Timetable
| Time | Program |
|---|---|
| 9:00–9:20 | Doors open |
| 9:20–9:30 | OpeningWelcome address Venue information and housekeeping notes |
| 9:30–11:20 | Lecture I: Kazuyuki Murakami |
| (Collect your lunch)11:20–11:30 Break | |
| 11:30–12:25 | Practice cases from companies taking part in the MBSE Learning JourneyListen at your ease over lunch.11:30 - 11:45: Case 1 (being arranged) 11:45 - 12:00: Case 2 (being arranged) 12:00 - 12:15: Case 3 (being arranged) 12:15 - 12:25: Case 4 (being arranged)four in all, 55 minutes |
| 12:25–12:30 Break | |
| 12:30–13:50 | Special lecture: David HetheringtonGiven in English with consecutive interpretation into Japanese. |
| 13:50–14:00 Break | |
| 14:00–14:50 | Special lecture: Prof. Hiroaki Takada |
| 14:50–15:00 Break | |
| 15:00–15:50 | Discussion and Q&A over tea: Prof. Hiroaki Takada, David Hetherington and Kazuyuki MurakamiTea and refreshments are served. Sit back and enjoy a discussion between professionals. Questions are welcome. |
| 15:50–16:00 Break | |
| 16:00–17:50 | Lecture II: Kazuyuki Murakami |
| 17:50–18:00 Break | |
| 18:00–18:10 | ClosingClosing address About the dinner reception |
| 18:30–20:30 | Dinner reception (choose whether you are attending at the payment step)Dinner is provided. Trade notes with others who care about MBSE, and widen both what you know and who you know. |
The program and its timings may change without notice.
The spine of the day is Kazuyuki Murakami’s talk in two parts, with the special lectures and the discussion among the three speakers set between them.
David Hetherington gives his talk and takes questions in English, with consecutive interpretation into Japanese. Put your questions in Japanese if you prefer: questions in Japanese are interpreted into English, and he speaks Japanese himself. The other talks are given in Japanese and are not interpreted into English.
Venue and directions
The venue is the YAMAHA MOTOR Regenerative Lab in Minatomirai, Yokohama (5-1-2 Minatomirai, Nishi-ku, Yokohama, Kanagawa 220-0012). The nearest station is Shin-takashima on the Minatomirai Line; for the way from Exit 4 (Rinko Park), see the venue’s official access page (in Japanese).
Registration and payment
What the fee includes
- A special lecture by Prof. Hiroaki Takada (50 minutes)
- A special lecture by David Hetherington (80 minutes)
- A two-part talk by Kazuyuki Murakami (3 hours 40 minutes in total)
- Discussion and Q&A with all three speakers (50 minutes)
- Practice cases from companies taking part in the MBSE Learning Journey (four in all, 55 minutes)
- Lunch, refreshments and dinner
- Reception (18:30–20:30, advance sign-up required)
Participation fee
General ¥8,000 plus tax (¥8,800 incl. tax) early-bird rate through Wed, Sep 30, 2026
General ¥12,000 plus tax (¥13,200 incl. tax) from Thu, Oct 1, 2026
Students ¥2,000 plus tax (¥2,200 incl. tax)
CapacityUp to 100 seats(sign-up ends once capacity is reached)Registration closesby Fri, Oct 16, 2026
- The Showcase is for people employed at an organization that develops or manufactures its own products or systems, engaged in the day-to-day work of development or production or responsible for its processes and competence management, and for university students who intend to work in development in the manufacturing industry. We ask everyone else not to register.
- The venue requires contact details and an affiliation for every attendee. Please register one person at a time, even when several of you are coming, and give your email address along with your company name, department and role (university, faculty and year of study for students).
- Photographs are taken at the venue during the day and may be used for publicity.
- Cancellations and refunds are not accepted once you have registered.
Payment and on the day
- Payment is completed on Stripe, an external payment service.
- If you were given a code in advance, please enter it when you pay.
- Stripe sends a receipt by email automatically once payment completes; please use that as your receipt. We do not issue receipts separately, and we cannot issue a qualified invoice under the Japanese invoice system.
- The details you need to enter the building are sent from the venue's own system, about a week before the event.
- If you register at the student rate, please show your student ID on the day.
- The dinner reception (18:30–20:30) requires advance sign-up. It is included in the fee; please say whether you are coming when you register.
- We cannot accommodate individual food allergies at the lunch, the refreshments or the reception.
- An excerpt of the slides is sent after the event to the email address you register with, within what each speaker agrees to release.
Bringing this to your manager
Attending costs a full working day and the trip to Yokohama. Here is a summary you can use as it stands when you raise it internally. It also answers the three objections that come up most often in that conversation: that this is for companies larger than ours, that it is an automotive matter, that it concerns the design department alone.
Internal noteBringing this to your managerOpenThe draft covers these points.SubjectWhen, where, costPurposeScopeDepartments concernedExpected benefitTime to benefitWhere this fitsQuestionsTrack recordCopy it and fit it to the form your company uses.
Subject: Attending MBSE Learning Journey Showcase 2026 Autumn
- When: Monday, 26 October 2026, 9:20–18:10 (reception 18:30–20:30)
- Where: YAMAHA MOTOR Regenerative Lab, 5-1-2 Minatomirai, Nishi-ku, Yokohama
- Cost: General ¥8,000 plus tax (¥8,800 incl. tax) at the early-bird rate through Wednesday, 30 September 2026, and ¥12,000 plus tax (¥13,200 incl. tax) from 1 October. Students ¥2,000 plus tax (¥2,200 incl. tax). All rates include lunch, refreshments and dinner at the reception
- Organiser: Liberal Logic Inc.
Purpose: To learn an MBSE methodology in a form that can be applied to real work. A two-part talk of 3 hours 40 minutes, given by a practitioner who has led the adoption of MBSE inside an organization, covers how the grounds for each decision across the life cycle defined by ISO/IEC/IEEE 15288 (concept, development, production, utilization, support, retirement) are brought together into a single model, and how that model is then checked for consistency. A correct understanding of the thinking behind the methodology is the starting point for planning how to apply it in our own organization.
Scope: MBSE is not a method for a particular industry or for large companies. The methodology addresses the life cycle defined by ISO/IEC/IEEE 15288, and that standard limits neither sector nor scale. Its 2023 edition, current as of September 2026, adds an annex on applying MBSE. Smaller organizations stand to gain the most from putting the grounds for their judgments into a form that stays, because a few people cover several roles and the key judgments rest with one experienced engineer. Reducing dependence on individuals, passing on expertise and keeping requirements under control are pressing concerns at any size of organization. Modeling does not have to cover everything. What to model should be selected on cost and benefit, starting with the parts that are complex, that change often, or that matter for safety and security.
Departments concerned: MBSE is not an activity of the design department alone. It establishes a shared language in which planning, sales, systems, software, hardware, safety, security and quality assurance can discuss the same model. The benefit therefore does not stop at one department. It extends to the quality of agreement and of handover between them. Attendance should follow the same principle. If several people attend, from the departments concerned rather than from design alone, what they bring back can be taken directly into a discussion across those departments.
Expected benefit: To bring back a concrete way of working that reduces rework and the waste caused by decisions resting on one person’s judgment, as material for improving the development process in our own department and in the departments it works with. The core of the day is a two-part talk of 3 hours 40 minutes by Kazuyuki Murakami, a practitioner who has been responsible for establishing MBSE inside an organization. The first part sets out the route the methodology takes, and the second covers how it is put into practice. The special lecture by Prof. Hiroaki Takada of Nagoya University, who has followed embedded systems development over many years, provides an assessment of where the field is heading. The special lecture by David Hetherington covers the area where MBSE meets functional safety and security. He leads the revision of the international standard for that area, SAE J3187-3.
Time to benefit: The benefit does not appear immediately after the event. Establishing MBSE requires initial effort for training and for building the first models, and results take years to become visible. Attending provides the whole picture, and the steps required, in a single day and before any commitment is made.
Where this fits: MBSE adoptions fail when they start with the tool. The order to follow is understanding systems thinking, agreeing a common process, adopting a methodology, preparing the guidelines, and selecting the tool last. This event covers the methodology, which is the stage before any tool decision. Ahead of a selection it serves as preparation for one; where a tool is already in place it serves as a check on what is missing to obtain value from it.
Questions: 50 minutes are set aside for discussion and Q&A with all three speakers, which can provide input on problems we face.
Track record
The points you are most likely to be challenged on are set out in Common misconceptions about adopting MBSE. Use them as they stand to clear up the usual misconceptions: “MBSE is for large companies”, “MBSE is for designers only”, “MBSE is for one particular industry”.
Useful reading (1): SYSMOD is the MBSE methodology devised and set down by Tim Weilkiens
What follows is useful reading to help you get more out of the day. It appears here by permission from Tim Weilkiens. Please do not reproduce it elsewhere. If it interests you, do buy the book from the SYSMOD page.
Methodologies, Languages, and Tools
SYSMOD becomes an MBSE methodology once it is combined with a modeling language and a modeling tool. Without them, it stands as a document-centric SE methodology. It is a good starting point. From there, based on your specific purpose, you derive your own customized SYSMOD-based methodology, a purpose-driven methodology. The SysML model elements you use, stereotypes included, and the modeling tool, customization included, are derived from that methodology. The methodology comes first; the language and the tool follow from it.
Methods, languages and tools are a triad. No one of them stands on its own. And what moves all three is the people at the center. The starting point is the purpose, entering from the left as an arrow.
The purpose sets the methods, and the methods settle how the language and the tool are used. When that order breaks down, you get the situation where a tool has been brought in and nothing has changed.
Useful readingSYSMOD – Pragmatic MBSE with SysMLOpenMBSE MethodologySYSMOD – Pragmatic MBSE with SysMLJudgments once left to instinct and experience, shared across the organization in a verifiable formSYSMOD is a MBSE toolbox for pragmatic modeling of systems. It is well-suited to be used with SysML. The toolbox provides a set of methods with roles and outputs. Concrete guidances and examples show how to apply the methods with SysML.
The main building blocks of SYSMOD
What SYSMOD sets down can be read from the SYSMOD ontology. Who does the work (Role), what work it is (Process), by what method (Method). What goes into that work and what comes out of it (Product). A methodology (Methodology) is the combination of these. The tool (Tool) is positioned as something that facilitates a Method.
In the diagram, the only line running from Tool is the one that facilitates Method. It is Method that the relationships gather around.
The SYSMOD domain knowledge model depicts that structure with the main concepts and their relationships. Each concept is set down as follows.
- Role: the competency profiles for the people who perform the methods and are responsible for the products
- Method: a collection of tasks that create significant artifacts for systems development
- Product: what goes into a method and what comes out of it; a role carries the responsibility for it
- Process: a basically reasonable logical sequence of how the methods can be executed
Skill and competence for each role
In Figure 1.1 just above, Role stood as one of the things a methodology is made of. SYSMOD also sets out the competence each role calls for. The figure below defines the competence of a system tester across nine skills, on a six-level scale ― seven if level 0, no skill, is counted.
| Level | Definition |
|---|---|
| 0 | No skills. |
| 1 | Exhibits knowledge of the topic. |
| 2 | Demonstrates an understanding of the topic and applies basic concepts. |
| 3 | Solves new problems by applying the knowledge. |
| 4 | Analyses the topic, makes inferences, and could easily apply the knowledge. |
| 5 | Combines elements in new patterns and propose alternatives. |
| 6 | Makes judgments about the topic and validates the quality of work. |
From Tim Weilkiens, SYSMOD – Pragmatic MBSE with SysML, 3rd Edition. Reproduced with permission.
Testing stands out, with SYSMOD, SysML and engineering discipline behind it; programming and system architecting sit lower. The shape of the competence a role calls for can be read at a glance.
This is the ground competence management stands on. Without it, an organization cannot put the right resources on a project. Who belongs in which role: place people without grounds for that judgment and the project stalls. Carrying a project through depends on managing competence.
The processes SYSMOD defines
A methodology does not work by being carried in as it is. An organization applies one by tailoring it to its own shape. SYSMOD defines that application as a process in its own right.
The upper half of the diagram is the work done by an organization’s senior, indirect and supporting functions: the Adoption Process that brings the methodology into the organization, and the Infrastructure Process that keeps it standing. The lower half is the people who use what the organization has put in place: the project manager, the requirements engineer and the system architect, working through the Analysis Process and the Architecture Process.
At a glance it looks like a diagram anyone could draw. But it is diagrams like this that let a structure which looks complicated be stated simply. Because it is simple it can be understood, and because it is understood people can talk about it. That is the order in which an MBSE methodology pays off on the floor.
The SYSMOD Infrastructure Process
The tailoring mentioned above is the first action in this process: Tailor the MBSE Methodology. From there three strands run in parallel: deploying it across the organization (Deploy the MBSE Methodology), putting training and coaching in place (Provide MBSE Training and Coaching), and setting up and keeping the modeling environment (Set up and maintain the SME).
The outcome of this process is that an MBSE methodology tailored to the organization has been deployed, with the environment to run it and the competence to use it both in place. Three outputs underpin that outcome.
- The MBSE methodology ― the methodology itself, tailored to the organization.
- The Systems Modeling Environment (SME) ― what it takes to actually run it.
- MBSE training ― the programme through which the people who use it build the competence.
Handing out a methodology on its own does not move an organization. The tailored methodology, the environment that runs it, and the training of the people who use it: the diagram shows the three advancing side by side.
The SYSMOD Analysis Process
It has much the same shape as the adoption process. What differs is the system it is applied to. The adoption process takes the MBSE methodology itself as its system; the analysis process takes the product you are setting out to develop. The same form, aimed at a different subject.
The system under consideration is called the System of Interest (SoI). An SoI is not confined to an engineered system: an organization, an institutional body, a management system. Anything made up of constituent parts is a system. A methodology is made up of parts too: roles and responsibilities, the competencies it calls for, methods, processes and artifacts. Make it an MBSE methodology and a modeling language and a modeling tool join them. Being a system itself, a methodology can be analysed as one and shaped into a system that fits the organization.
The outcome of this process is that the problem and the objectives are clear, and there is agreement with the stakeholders on what is to be built and whose requirements it answers. The outputs that underpin that outcome:
- Base Architecture
- Domain Knowledge
- Requirements
- Risks
- Stakeholders
- System Context
- System Idea
- System Objectives
- System Processes
- System Use Cases
- Use Case Activities
These are not separate documents. They are tied to one another inside a single model, and that is what makes the whole checkable for consistency. The diagram looks dense because every one of those relationships is drawn.
The SYSMOD Architecture Process
Where the analysis process settles what is to be built, the architecture process settles how it is put together. The artifacts the analysis process produced, namely the system context, the requirements, the base architecture and the system use cases, become its inputs.
The outcome of this process is that a structure satisfying the requirements has been settled on, and the reason for that structure can be traced back to the requirements. The outputs that underpin that outcome:
- Logical Architecture
- Product Architecture
- Scenario
- System State
FAS (Functional Architectures for Systems) is a technique that complements SYSMOD. The functional architecture marked «Optional» on the left of the diagram is what FAS produces. The concept and the detail of the FAS method are set out in the book Model-Based System Architecture, Second Edition.
Which architecture are we talking about?
Base architecture, logical architecture, product architecture, test architecture, functional architecture: a good many architectures have gone past by now. Have you ever sat in a meeting where someone said “the architecture” and you could not tell which one they meant?
SYSMOD keeps them apart as types.
System Architecture and Physical Architecture are in italics: they are abstract, and nothing exists as one. Say “the architecture” on its own and you have named nothing. What matters is being explicit about which architecture is meant, and keeping them apart.
Tailoring general-purpose SysML to your own organization
SysML is a general-purpose language. Built to describe any system at all, it is not, as it stands, the language of the work in front of you. So you add vocabulary to fit the organization. What SYSMOD lays down is a set of extensions (stereotypes) like these. There are others; for the fuller picture, see the SYSMOD book.
Actors first. The SysML Actor gains names: user, external system, sensor, actuator, mechanical system, boundary system. Effects on the environment are typed as well.
Then disciplines. Whether an element is software, mechanical or electrical is carried as a type. If you had taken MBSE to be a software matter, this may come as a surprise.
Blocks are no different: system, subsystem, system context, domain block, document block, user interface. The «domainBlock» and «systemUseCase» markings that have appeared in figure after figure above are vocabulary defined here.
Handing over a general-purpose language moves no one. It has to be tailored to the organization. That is what stood first in the infrastructure process.
Useful reading (2): What the MBSE methodology changes
Decisions that were settled come undone later. Cross a department boundary and the assumptions no longer match. The only person who knows why something was decided is the person who decided it. Rework is what that accumulates into. The cause is that the grounds for those decisions sit scattered across specifications, meeting notes and individual memory. Scattered, they can contradict one another without anyone noticing. It comes to light only when implementation is far enough along that it is too late. Following the methodology, everything from the market requirement through to the design decision is brought into a single model. Only once it is brought together can the whole be checked for consistency. And because the subject is captured in the abstract, engineers stay free to choose any concrete design that satisfies it.
Adopting a methodology such as SYSMOD does not merely mean that people start drawing models. It changes how the organization decides, how it develops, how it reviews and how it grows its people.
Useful readingWhat the MBSE methodology changesOpenExpected outcomesWhat the MBSE methodology changesTen changes to expect from SYSMODOrganizations that struggle with systems engineering and MBSE tend to share the same traits:Vague requirementsWeak collaboration across departmentsNo design rationale left behindProblems found lateDependence on individualsThose are the traits.Let us look at the changes to expect from adopting SYSMOD.
Change 1. From requirement-driven to purpose-driven
Before
- Customer requirements are implemented as given
- Why they are needed is unclear
- Requirement changes are hard to absorb
After
- Organized from stakeholders, concerns and goals
- The reason the system exists is explicit
- Impact can be analyzed when requirements change
Expected outcomes
- Less rework caused by requirements
- Better requirement quality
- Better agreement with the customer
- Impact of requirement changes traced
Change 2. Functional design becomes systematic
Before
- Straight into ECU design
- Discussion starts from software design
After
- System Contextlooking in from the environment the system sits in, to fix its boundary and exchanges
- Use Case
- Functional Architecturea functional design with no physical dependency
- Logical Architecturea stable design, unaffected by the actual parts
- Product Architecturea design tied to the actual parts and weak against change
in that order
Expected outcomes
- No jumping to solutions
- Fewer missing functions
- The effect of a part change stays local
Change 3. Departments gain a shared language
Before
- Mechanical
- “That part belongs to mechanical”
- Software
- “That is the mechanical side’s problem”
- Electrical
- “The requirements are not clear to us”
After
Everyone looks at the same model
- Requirements
- Use Cases, and the Activities that describe what happens inside them
- Blocks, Ports, Flowsthe static design of the architecture
- Interactionsbehaviour between blocks
- State Machine(s)behaviour of the System of Interest as a whole
are shared
Expected outcomes
- Less mismatch between departments
- Less time in meetings
- More efficient reviews
Change 4. From document-centered to model-centered
Before
- 500 pages of Word
- 200 slides of PowerPoint
- Excel everywhere
After
- The model is the single source of truth
- Documents, reports and the like are generated from the model
Expected outcomes
- Better document consistency
- Fewer missed updates
- Better maintainability
Change 5. Design rationale is retained
Before
- Why it was designed this way is unknown
- It disappears when a veteran retires
After
- Design decisions recorded as model elements
- The reasons for the choice kept in the model description
Expected outcomes
- Knowledge is handed on
- Better accountability for design
- More efficient onboarding
Change 6. The review culture changes
Before
What gets reviewed
- Nothing but the parent requirement on the left and your own on the right, in the requirements management tool
- Whether the traces are in place is visible
- The quality of the requirements themselves rests on the reviewer’s experience
After
What gets reviewed in SYSMOD
- Requirements
- Use Cases
- Activitiesuse case activities
- Domain Blockthe vocabulary that surfaced during requirements analysis
- Test Cases
set against one another
Expected outcomes
- Better upstream quality
- Requirements checked from several angles
Note
Checked on each individual requirement ― Necessary / Appropriate / Unambiguous / Complete / Singular / Feasible / Verifiable / Correct / Conforming (ISO/IEC/IEEE 29148 5.2.5 Characteristics of individual requirements)
Checked on the set of requirements ― Complete / Consistent / Feasible / Comprehensible / Able to be validated (ISO/IEC/IEEE 29148 5.2.6 Characteristics of a set of requirements)
Change 7. Problems surface earlier
Before
Problems are found at
- Integration testing
- Testing on real hardware
After
At model review
- Contradictory requirements
- Missing functions
- Interface mismatches
are found
Expected outcomes
- Far lower cost of correction
- Less rework downstream
Change 8. Safety and security work is integrated
Before
- Quality and reliability
- ISO 26262
- ISO/SAE 21434
run as separate activities
After
On the same model
- Riskquality and reliability
- Hazardfunctional safety
- Threatcybersecurity
are managed
Expected outcomes
- Better traceability
- Better consistency
- More efficient audits
Change 9. From person-dependent to organization-wide development
Before
- “Only that person understands it”
After
- The model and its supporting documents become an asset
Expected outcomes
- Less dependence on key people
- Lower risk when people move on
- Easier global development
Change 10. Systems thinking takes root in the organization
This is the largest change of all.
Before
- Optimizing the part
- Optimizing the department
- Optimizing the project
After
- Optimizing the system
- Optimizing the lifecycle
- Optimizing the business
becomes how people think
Expected outcomes
- Local optima give way to the whole
- An optimal life cycle
- Engineering tied to business judgment
Changes seen from the management side
Once it has matured, roughly three to five years after SYSMOD is adopted,
can be expected.
Put the other way round, the real value of SYSMOD is not in drawing more SysML diagrams. It is in embedding systems thinking in the organization and turning development that depends on individual experience and intuition into a repeatable engineering process.
In the automotive industry, where the investment has run ahead, complex system development such as ADAS, autonomous driving, SDV and cybersecurity is becoming the norm, so the gap between organizations that have adopted SYSMOD and those that have not is likely to widen further.
In aviation, showing how requirements, design and safety assessment correspond has long been a precondition for type certification. The development process set out in ARP4754, currently revision B of December 2023, is systems engineering itself, and the practice of keeping the grounds for each decision in a traceable form is already well established there. What other industries are only now being asked for, through their functional safety and cybersecurity standards, has been taken for granted in this field for a long time.
Useful reading (3): Common misconceptions about adopting MBSE
There are a great many misconceptions about adopting an MBSE methodology, and SYSMOD in particular. Those misconceptions are why adoptions fail, and why the effects that were expected never arrive.
The first three are about what the words point to. As long as that is off, nothing that follows will line up.
Read the misconception against what happens in practice, and take it as a hint toward what MBSE really is.
Useful readingCommon misconceptions about MBSEOpenPoints to watchCommon misconceptions about MBSEFifteen assumptions seen in the fieldThese are the ones you meet most often.Systems engineering is a job titleDoing MBD means doing MBSEMBSE means drawing SysMLBuying a tool makes it succeedEverything has to be modeledThe model replaces the specificationDevelopment gets shorterHaving modelers is enoughIt is for large companiesOur design is too small for itIt is for designers onlyIt solves requirement qualitySYSMOD is a drawing guideStarting with tool and trainingIt is for one industrySet each misconception against what happens in practice, side by side.
Misconception 1. Systems engineering is a job title
Misconception
- “It means the work of a systems engineer”
- “It is something the IT department deals with”
- “It is one of the software development roles”
In practice
Systems engineering is the name of a discipline, not the name of a job.
- Its scope is the whole life cycle set out in ISO/IEC/IEEE 15288
- It is a way of thinking, and a set of steps, for making a system hold together across several specialist fields
- It is carried not by one job title but by several roles: planning, design, safety, quality
Note
In many languages the words for the job and for the discipline are all but identical. They only sound alike. What they point to, and how far they reach, are different things.
The “SE” in MBSE (Model-Based Systems Engineering) is the discipline of systems engineering, not the job of a systems engineer.
Misconception 2. Doing MBD means doing MBSE
Misconception
- “We build models in Simulink, so we are doing MBSE”
- “We adopted model-based design (MBD) long ago”
- “We run simulations and generate code automatically”
In practice
MBD and MBSE work on different things.
- MBD works mainly on how a function that has been settled is realized. It builds control laws and behavior in executable form and checks them by simulation and code generation
- MBSE works on what should be built, and on why it was decided that way. It ties purpose, requirements, functions, architecture and the reasoning behind each decision into one model
Note
They are different, but they are not rivals. They pay off once they are connected.
- The functions and interfaces settled on the MBSE side become the rationale for what the models on the MBD side have to realize
- The analysis results from the MBD side become the evidence behind design decisions on the MBSE side
An existing MBD practice is not an obstacle to adopting MBSE. It is what MBSE connects to.
Misconception 3. MBSE means drawing SysML
This is the most common misconception of all.
Misconception
- “We have had SysML training, so we can do MBSE”
- “We bought the tool, so we have adopted MBSE”
In practice
The essence of MBSE is
- systems thinking
- structuring information
- traceability
- making decisions visible
Note
SysML is only a means of expression.
Taken to the extreme,
- you can be drawing SysML and still not be doing MBSE
- you can think in an MBSE way without using SysML
and both are true.
Misconception 4. Buying an MBSE tool makes it succeed
Misconception
- We installed Cameo
- We installed Magic Cyber Systems Engineer
- We installed Enterprise Architect
therefore MBSE has succeeded
In practice
A tool is only an instrument.
Buying a hammer does not make you a carpenter.
Success needs
- a methodology
- training
- governance
Note
What actually happens, more often than not, is that expensive licenses stay in the hands of a few people and the low rate of use only becomes apparent when they come up for renewal.
Misconception 5. Everything has to be modeled
Misconception
- “We will model 100% of the system”
In practice
Cost-effectiveness decides.
What should be modeled is
- the complex parts
- the parts that are hard to share
- the parts that change often
- the parts that matter for safety and security
Note
SYSMOD, too, assumes that you model according to your purpose.
Misconception 6. The model replaces the specification
Misconception
- “We will not need Word any more”
In practice
In reality
- contract documents
- regulatory submissions
- customer deliverables
- documents generated from the model
are still required.
Note
The right way to see it is that the model is the master and the documents are generated from it.
Misconception 7. Adopting MBSE shortens development
Misconception
From the moment it is adopted
- rework goes down
- efficiency goes up
- development gets shorter
In practice
At first the opposite happens.
Early on
- investment in training
- the effort of building models
- changing the process
push productivity down.
Note
The usual pattern is
- Year 1: confusion
- Year 2: it begins to settle
- Years 3 to 5: the effects show
What looks like extra effort is not new work. It is the work that always had to be done, which a document-centric approach kept out of sight. The difference is whether quality problems are drawn out early, upstream in design, or dealt with later, once the product is in the field.
Misconception 8. Having modelers is enough
Misconception
- “We just need people who can draw SysML”
- “A course on the modeling tool will get it running”
- “A few dedicated modelers are enough to start”
- “Leave the drawing to them; everyone else carries on as before”
In practice
What is really needed is
- Systems Engineer
- Requirements Engineer
- System Architect
- System Tester
- Project Manager
- MBSE Admin
- MBSE Methodologist
- Domain / Discipline teams
Note
Modeling skill matters, but what to think about matters more than how to draw it.
Misconception 9. MBSE is for large companies
Misconception
- Only large OEMs need it
In practice
Smaller organizations often gain more.
The reason is that it works on
- dependence on individuals
- handing on expertise
- requirement management
Note
Where an organization depends on one veteran, the effect is especially large.
Misconception 10. Our design is not big enough for MBSE
Misconception
- The product is small, with few parts
- Drawings and a specification are enough
In practice
The measure is not size. It is how many decisions there are and how far they reach into each other.
Even a small product is worth recording the grounds for if any of these applies:
- several disciplines are involved (mechanical, electrical, software)
- the specification changes again and again
- the grounds for safety or security have to be explained
Nor does the model have to cover everything. Start where it is complex, where it changes often, or where safety and security turn on it, and choose by cost and benefit.
Note
Size changes later. Starting once the design has grown costs more than keeping the grounds on record from the outset.
Misconception 11. MBSE is for designers only
Misconception
- Something the design department does
In practice
It is there to connect
- planning
- sales
- systems
- software
- hardware
- safety
- security
- quality assurance
Note
MBSE is less a design technique than a way of communicating across the organization.
Misconception 12. MBSE solves requirement quality problems
Misconception
- Modeling raises the quality of requirements
In practice
- If the requirements are vague, the model will be vague
- Garbage in, garbage out
Note
MBSE makes problems with requirement quality visible; it does not solve them by magic.
Misconception 13. SYSMOD is a guide to drawing diagrams
This is the classic misconception about SYSMOD.
Misconception
Something that teaches
- how to draw use case diagrams
- how to draw activity diagrams
- how to draw block definition diagrams
In practice
What SYSMOD really defines is
- how to understand the system
- in what order to think
- what to decide
- what to review
Note
In other words, it is closer to a way of thinking about systems development than to a modeling methodology.
Misconception 14. Starting with the tool and the training gets you there
Misconception
Adoption is a matter of working through this order:
- introduce the tool
- run SysML training
- hand it to the engineers and walk away
In practice
The keys to a successful adoption are
- learn systems thinking
- adopt a methodology such as SYSMOD
Note
This order is the one you see most often in Japanese manufacturing. What follows is an organization where the diagrams increased and the development did not change.
Misconception 15. MBSE is for one particular industry
Misconception
- A method for automotive and aerospace
- Nothing to do with our industry
In practice
The method is not tied to an industry.
What the MBSE methodology addresses is the life cycle as ISO/IEC/IEEE 15288 sets it out, and that standard limits neither industry nor scale. The 2023 edition adds an annex on applying MBSE.
Wherever several disciplines meet and the grounds for a decision have to be kept, it works, whatever the industry.
Note
What ISO/IEC/IEEE 15288 sets out is the frame of the life cycle. It could not carry the work on its own. It is used together with standards such as these, and with many others besides:
- ISO/IEC/IEEE 29148 ― requirements engineering
- ISO/IEC/IEEE 42010 ― architecture description
- ISO/IEC/IEEE 29119 series ― testing
- ISO/IEC/IEEE 15289 ― documentation
- ISO/IEC/IEEE 15939 ― measurement
None of these is tied to an industry either.
The examples lean toward automotive and aerospace because regulation and safety requirements bore down early there and the investment came first. That is not a limit of the method itself.
Summary
In a word, MBSE is not a modeling activity. That is the biggest misconception about adopting it.
In practice, MBSE is a change program that embeds systems engineering in the organization, and the model is no more than the medium for it.
Seen that way, the value of SYSMOD is not in producing more SysML diagrams. It is in making the organization’s decisions repeatable and explainable.
Frequently asked questions
These are the questions we are asked most often.
About the event
What is this event for?
To give you an understanding of an MBSE methodology (SYSMOD) in a form you can apply to your own work. The aim is that you leave with an answer to the question that stops people even after they have read the books and tried the tools: how do I use this on my own floor?
So the day is not built around listening alone. Its spine is a talk in two parts by Kazuyuki Murakami, who has put an MBSE methodology to work in industry; around it sit the special lectures by David Hetherington and Prof. Hiroaki Takada, the practice cases from the companies taking part in the MBSE Learning Journey, and a discussion and question session with all three speakers. After the event we send everyone who attended an excerpt of the slides.
MBSE Learning Journey is a free, invitation-only study group where practitioners from manufacturers learn an MBSE methodology together. The Showcase opens what the group has built up to a wider circle than the invitation list reaches, and widens the place where people in manufacturing can sharpen one another.
Is this a sales event? Is there something behind it?
No. The parent study group, MBSE Learning Journey, is free and invitation-only, designed purely as a place to study the engineering, not a place for sales activity. The Showcase follows from it: nothing in the talks, the practice cases or the discussion is a pitch for a product or a service. None of the three speakers is an employee of the organiser; each speaks from their own position.
Liberal Logic Inc. is not a consultancy but a manufacturer, and not a business that sets out to make money from events of this kind. What we are after comes from a plain reading of the situation Japanese manufacturing is in today: that all of us in manufacturing, ourselves included, are better off with a place to sharpen one another. We have also been fortunate in the people who have given us their time, their knowledge and their judgement. This event is simply the result of wanting to pass that on, as far as we are able. For Liberal Logic, the organiser, it is an occasion to have this work become known, but that is a consequence, not the purpose.
If it is not run for profit, why is there a fee?
There are two reasons.
One is cost. Honoraria for the speakers, the moderator, consecutive interpretation, photography, and lunch, refreshments and dinner at the reception together come to more per attendee than the participation fee. The fee covers part of it.
The other is to keep registration to people who genuinely intend to come. Make a 100-seat in-person event free, and some of those who register never arrive, which shuts out people who wanted to be there. The student rate of ¥2,200 holds to that principle while lowering the barrier.
The general fee comes in two stages: it rises once the early rate expires. The dates and the amounts are set out under Registration and payment. The student rate stays the same throughout.
Registration and payment
I am outside the intended audience (a consultancy, a recruitment firm and so on). May I attend?
Please refrain from registering. The Showcase is for people employed at an organization that develops or manufactures its own products or systems, engaged in the day-to-day work of development or production or responsible for its processes and competence management, and for university students who intend to work in development in the manufacturing industry. The day is built for them to bring the questions from their own floor and to take back hints towards answering them.
Cancellations and refunds are not accepted once you have registered. If you are unsure whether you fall within the intended audience, please get in touch before you pay.
Can my company pay by invoice, or after the event?
No. Payment is handled through the external payment service (Stripe) only.
Stripe sends a receipt by email automatically once payment completes; please use that as your receipt. We do not issue receipts separately.
Can I cancel and get a refund after registering?
No. Cancellations and refunds are not accepted once you have registered. Your registration is final the moment payment completes.
The attendee cannot be changed either, so please make sure the date works for you before you register.
Can I register several people at once? Can I send someone else in my place after registering?
Neither is possible. Both the registration and the building’s entry system are keyed to an email address, so each person attending needs to register themselves, one at a time. For the same reason, the attendee cannot be changed once registered.
Registering asks for an email address and, alongside it, the company, the department and the work you are responsible for (for university students, the school, the faculty and the year). If several of you are coming, each person registers separately.
Can I add the dinner reception later?
No. Please choose whether you are attending at the time you register.
The reception (18:30–20:30) has to be booked in advance and is included in the participation fee. There is nothing extra to pay if you join it.
On the day
How does entry to the building work on the day?
The details you need to enter the building are sent from the venue’s own system, about a week before the event. They come from the venue rather than from us. On the day, follow what that message tells you.
Will the slides be handed out or published?
Yes. After the event we send an excerpt to the email address you registered with, so that you can take the thinking behind systems engineering and MBSE back to your own workplace.
What the excerpt covers is what each speaker agrees to release. We send it once that agreement is in hand, so it does not arrive immediately after the event. We ask you not to share it outside your own organization or on social media.
Are there rules about recording, dress, or leaving partway through?
- No video, audio or photography. Note that photographs are taken at the venue during the day and may be used for publicity.
- There is no dress code. Come in casual clothes.
- You are free to come and go. The building runs its own security system; if something goes wrong with it, we are not able to step in or to compensate you.
I am an English speaker. What happens with the talks by Kazuyuki Murakami and Prof. Takada?
The event is held for a Japanese-speaking audience, so there is no interpretation into English for the talks by Kazuyuki Murakami and Prof. Hiroaki Takada.
What you can follow in English is the special lecture by David Hetherington (80 minutes) and the questions that follow it. He speaks in English, with consecutive interpretation into Japanese. Questions put to him in Japanese are interpreted into English, so you can follow that exchange as well. He also converses and reads in Japanese.
Which talk is held in which language is set out below the timetable.
About the content
Do I need prior knowledge of SysML or MBSE?
No prior knowledge is needed. If you are serious about changing the way engineering work is done, we believe the day will be worth it.
If you would like to read something beforehand, there are three pieces on this page. You are welcome to come without reading them.
Will I be lost if I did not attend the June edition with Tim Weilkiens?
No. This edition stands on its own.
The June edition was a keynote and a dinner reception with Tim Weilkiens, co-author of SysML v1 and v2, who joined us from Germany. There is a record of the day on the June 18, 2026 edition page.
Is this about a particular tool?
No. The content does not depend on any tool.
MBSE adoptions fail when they start with the tool. The order to follow is understanding systems thinking, agreeing a common process, adopting a methodology, preparing the guidelines, and selecting the tool last. This event covers the methodology, which is the stage before any tool decision. Ahead of a selection it serves as preparation for one; where a tool is already in place it serves as a check on what is missing to obtain value from it.
About MBSE Learning Journey
How can I join the MBSE Learning Journey itself?
We are sorry to say that it is invitation-only, on the recommendation of someone connected with the group.
The Showcase exists to open what the MBSE Learning Journey has built up to a wider circle than the invitation list reaches.