The goal of MMEL modeling is to capture requirements from standards documents in an unambiguous, machine-readable model. The model represents the structure, processes, data, and compliance requirements defined in the source document.
There is no single correct model for a given standard. Multiple valid models may exist, each representing a legitimate interpretation of the source text. The modeler makes design decisions about how to structure the model, and different modelers may arrive at different but equally valid solutions.
This guide describes the methodology and principles for creating MMEL models. For instructions on using the MMEL editor tool, refer to the MMEL Authoring Guide .
The following principles guide the modeling process:
Before beginning to model, thoroughly read and understand the source document. The modeler should have a clear comprehension of the document's purpose, scope, and requirements.
The model must preserve the exact wording of the source document. Do not paraphrase, reword, or summarize requirement text. The original language must appear verbatim in provisions.
Do not add content that does not appear in the source document. The model should faithfully represent what is in the document -- nothing more, nothing less.
Every requirement, process, and data element in the source document should have a corresponding representation in the model. The model should achieve 100% coverage of the source text.
Model the main body of the standard. Ancillary materials such as forewords, introductions (unless they contain normative requirements), and informative annexes are generally modeled as sections only, unless they contain requirements that need to be captured as provisions.
When deciding between a more detailed and a less detailed representation, prefer the more detailed option. Greater detail provides better traceability and reduces ambiguity.
The following measures are used to assess model quality:
In general, a higher number of model elements is preferable. More elements indicate that the modeler has thoroughly decomposed the source document into its constituent parts.
The model should cover 100% of the normative content in the source document. Every requirement, process definition, data structure, and compliance obligation should have a corresponding model element.
The model should contain zero semantic-equivalent elements. That is, no two elements should represent the same concept from the source document. Each concept should be modeled exactly once.
Model quality is ultimately judged manually by reviewing the model against the source document. The measures above serve as guidelines, but human review is essential to ensure:
The following challenges are commonly encountered during modeling:
Modelers who are unfamiliar with the domain of the standard may misinterpret requirements. Understanding the subject matter is important for creating an accurate model.
Some terms in standards are inherently ambiguous. For example, the word "applicable" may be interpreted differently depending on context:
Different modelers may interpret the same document differently, leading to structurally different but semantically equivalent models. This is expected and acceptable, provided each model accurately represents the source document.
The following mappings describe how common parts of a standard are represented in the model:
| Source content | Model component |
|---|---|
| Standard number | Namespace (e.g.,
BS6004
) |
| Foreword, Introduction, Scope, Normative references | Model sections |
| Terms and definitions | Model terms |
| Figures | Multimedia (Figure type) |
| Tables | Model tables |
Flow patterns in the source text are identified by specific language cues and mapped to MMEL flow components:
The requirement to perform an activity is modeled as a Process. Typical indicators include:
The requirement for someone to approve something is modeled as an Approval:
References to time periods or intervals are modeled as Timer events:
Conditional language that creates branching is modeled using Gateways:
When Process 1 must be completed before Process 2 begins, the processes are connected by an edge in series:
[Start] -> [Process 1] -> [Process 2] -> [End]When both processes are required but no specific order is mandated, they are modeled as parallel paths. Both must be completed for the overall flow to be satisfied.
When a process is repeated, it may be connected back to itself, typically with a Timer event:
[Process] <- [Timer (REPEAT)]When a gateway has conditions on its outgoing edges, the flow takes the path whose condition is satisfied:
[Gateway] -- condition A --> [Process A]
|- condition B --> [Process B]When a gateway has no conditions, the flow is fulfilled if any one of the outgoing paths is fulfilled (like an OR gateway):
[Gateway] --> [Process A]
|-> [Process B]
(fulfilled if either A or B is completed)The modeling process follows three steps:
Identify all provisions in the source document. Each provision is a basic unit consisting of:
Group provisions under processes. Determine:
Every subprocess becomes a diagram. Create diagrams for each subprocess and populate them with the appropriate flow components:
This section demonstrates the complete modeling process for BS 202000 clause 9.2.1 on internal audits.
The clause requires the organization to conduct internal audits. The key requirements are identified as follows:
The primary process -- the organization must conduct internal audits:
process ConductInternalAudit {
actor Organization
modality SHALL
}The audit must check that the SMS (Safety Management System) conforms to:
These actions form a subprocess of the overall audit process:
process PlanAuditProgram {
actor Organization
modality SHALL
}
process EstablishAuditProgram {
actor Organization
modality SHALL
}
process ImplementAuditProgram {
actor Organization
modality SHALL
}
process MaintainAuditProgram {
actor Organization
modality SHALL
}process DefineAuditCriteriaAndScope {
actor Organization
modality SHALL
}process SelectAuditor {
actor Organization
modality SHALL
}process ConductAudits {
actor Organization
modality SHALL
}process ReportAuditResults {
actor Organization
modality SHALL
}process TakeCorrection {
actor Organization
modality SHALL
}The source text states audits must occur "at planned intervals," which is modeled with a Timer event:
timer_event PlannedIntervals {
mode REPEAT
value "planned intervals"
}The documentation requirement forms an independent path in the diagram, representing record-keeping that occurs alongside the audit process.
This section provides a full walkthrough of creating measurements in a model, using BS 6004 clause 7.3 as an example.
BS 6004 clause 7.3 defines test requirements for electric cables. The tabulated data in Tables 3 through 6 specify the relationship between cable parameters and their acceptable test values.
The first step is to create a database table from the tabulated data in the standard. BS 6004 Tables 3 through 6 contain 67 records of cable test parameters.
Create a table in the model and populate it with the data from the source tables:
table CableTestData {
class CableTestData#data
source "Tables 3-6, BS 6004"
record_count 67
}Import the data from CSV or enter it manually using the Table view.
Define measurement variables that correspond to the input parameters the user will provide:
measurement tm {
type NUMERIC
description "Measured test value"
}
measurement cable_type {
type TABLE_OPTIONS
table CableTestData
column "cable_type"
description "Type of cable under test"
}
measurement cross_section {
type TABLE_OPTIONS
table CableTestData
column "cross_section"
description "Cross-sectional area of conductor"
}
measurement conductor_class {
type TABLE_OPTIONS
table CableTestData
column "conductor_class"
description "Class of conductor"
}The
TABLE_OPTIONS
type creates a drop-down selection populated from the values in the specified table column.
Define derived measurements that look up values from the database table:
measurement tn {
type TABLE_REFERENCE
table CableTestData
column "tn"
lookup_by ["cable_type", "cross_section", "conductor_class"]
description "Nominal test value from reference table"
}The
TABLE_REFERENCE
type performs a table lookup using the specified key columns. The value of
tn
is automatically determined based on the user's selections for
cable_type
,
cross_section
, and
conductor_class
.
TABLE_OPTIONS
measurement variables present the user with a choice from values found in a specific column of the database table. This ensures that the user can only select values that exist in the reference data.
measurement cable_type {
type TABLE_OPTIONS
table CableTestData
column "cable_type"
}TABLE_REFERENCE
measurement variables derive their value by looking up a record in the database table that matches the user-provided key values. This is used to retrieve reference values such as nominal test thresholds.
measurement tn {
type TABLE_REFERENCE
table CableTestData
column "tn"
lookup_by ["cable_type", "cross_section", "conductor_class"]
}Once the measurements are defined, add a measurement test to the relevant process. The test evaluates whether the measured value meets the acceptance criterion.
For BS 6004 clause 7.3, the test checks whether the measured value
tm
is within the acceptable range relative to the nominal value
tn
:
process TestCable {
actor TestingLaboratory
measurement_test "[tm] <= 0.9 * [tn] - 0.1"
validate_provision P_7_3
}In this test:
After defining the measurements and tests, use the Model Viewer to verify the model:
This interactive testing ensures that the measurement model behaves correctly before deployment.
This section provides a walkthrough of modeling conditional requirements using gateways and edge conditions, using BS 13485 clause 6.4.2 as an example.
BS 13485 clause 6.4.2 contains requirements for contamination control. Some requirements apply only when the organization manufactures sterile medical devices, creating a conditional branch in the model.
A Gateway is used to represent the conditional logic: "if the organization manufactures sterile medical devices, then additional requirements apply."
gateway SterileDeviceCheck {
description "Does the organization manufacture sterile medical devices?"
}The gateway splits the flow into two paths:
The condition is modeled as a Boolean parameter that can be toggled:
This creates a parameterized view where the model can represent different configurations depending on the organization's context.
The outgoing edges from the gateway carry conditions that determine which path is taken:
edge SterileDeviceCheck_to_SterileRequirements {
condition "[sterile] = 'true'"
description "Organization manufactures sterile medical devices"
}
edge SterileDeviceCheck_to_GeneralRequirements {
condition "[sterile] = 'false'"
description "Organization does not manufacture sterile medical devices"
}When the model is viewed or executed:
The additional requirements for sterile medical devices are modeled as processes connected via the gateway:
process ControlContamination {
actor Organization
modality SHALL
validate_provision P_6_4_2_a
}
process ControlMicrobiologicalContamination {
actor Organization
modality SHALL
validate_provision P_6_4_2_b
condition "[sterile] = 'true'"
}The resulting diagram has the following structure:
[Start] -> [ControlContamination] -> [Gateway: SterileDeviceCheck]
|
+--------------+--------------+
| |
[sterile = true] [sterile = false]
| |
[ControlMicrobiological [End]
Contamination]
|
[End]The following enhancements are planned for branching and conditional modeling:
Future versions will support OCL (Object Constraint Language) for more expressive conditions:
edge Gateway1_to_ProcessA {
condition_ocl "self.sterile = true and self.riskLevel > 3"
}The model viewer will provide real-time validation feedback, indicating which paths are active based on the current parameter values and highlighting any conflicting or unreachable paths.
A graphical user interface for setting edge conditions and measurement formulas is planned, allowing modelers to build conditions visually rather than typing formulas manually.
Future versions will support using data class attributes directly in conditions, enabling more complex conditional logic based on structured data:
edge Gateway1_to_ProcessA {
condition "[device.isSterile] = true"
}