MN 113-3: MMEL Process Modelling

1.1. General

This document specifies the process modelling facilities of the Multi-Modal Modelling Language (MMEL), as defined in MN113 . MMEL process modelling provides BPMN-style behavioural diagrams integrated with compliance tracking, measurement validation, and data register I/O.

The process modelling subsystem of MMEL encompasses:

• processes -- behavioural units representing tasks or activities, optionally bound to compliance provisions, measurement validations, and data registries
• events -- start events, end events, timer events, and signal catch events that control the lifecycle and timing of process flows
• gateways -- exclusive decision points where exactly one outgoing path is taken based on a condition
• approvals -- specialized process elements representing approval workflows with designated approvers and optional data registry storage
• subprocesses -- diagram containers that organize elements, flow edges, and data store placements into visual process flow diagrams
• process flow edges -- directed connections between elements, optionally carrying descriptions and conditions for gateway branching

1.2. Relationship to BPMN

MMEL process modelling is a superset of BPMN (Business Process Model and Notation) concepts. The following table maps BPMN concepts to their MMEL equivalents:

1.3. What MMEL adds beyond BPMN

MMEL extends BPMN with the following capabilities:

• Compliance bindings -- processes carry validate_provision { } properties that bind them to regulatory provisions with RFC 2119 modality keywords
• Measurement validation -- processes carry validate_measurement { } properties with quantitative expressions (e.g. ” [X] >= 0.95 “ ) for KPI monitoring
• Data register I/O -- processes explicitly declare output { } and reference_data_registry { } bindings to persistent data stores
• Cross-model links -- processes reference external models via links { } properties
• Normative traceability -- all compliance bindings trace back to normative document clauses via reference declarations
• Tabular and figure content -- processes may reference table { } and figure { } definitions containing structured data or embedded images

1.4. Node types

MMEL supports the following node types within process flow diagrams:

1.5. Process reuse

A process definition can appear in multiple subprocess diagrams. When the same process ID is placed in multiple subprocess elements sections, all instances share the same definition -- including name, actor, modality, provision bindings, measurement validations, and data bindings.

Updating a process definition updates it everywhere it is used. This ensures that compliance obligations and data bindings remain consistent across all diagrams that reference the process.

2.1. General

Processes are the core behavioural units in MMEL. They represent tasks, activities, or operations within the model, and may carry compliance obligations, produce data outputs, consume data inputs, and contain measurement validation expressions.

2.2. Syntax

process <ProcessID> {
  name "Display name"
  actor <RoleID>
  modality SHALL | SHOULD | MAY | CAN | MUST
  validate_provision {
    <ProvisionID1>
    <ProvisionID2>
  }
  validate_measurement {
    "<measurement expression>"
  }
  output {
    <DataRegistryID1>
    <DataRegistryID2>
  }
  reference_data_registry {
    <DataRegistryID1>
    <DataRegistryID2>
  }
  subprocess <SubprocessID>
  links {
    <LinkID1>
    <LinkID2>
  }
  note {
    <NoteID1>
    <NoteID2>
  }
  table {
    <TableID1>
    <TableID2>
  }
  figure {
    <FigureID1>
    <FigureID2>
  }
}

1. Display name of the process. Required.
2. The role responsible for performing this process. Optional.
3. Modality keyword indicating the obligation level. Optional.
4. Provisions this process must satisfy. Optional.
5. Measurement validation expressions. Optional.
6. Data registries this process writes to. Optional.
7. Data registries this process reads from. Optional.
8. Links to a child subprocess containing the detailed flow. Optional.
9. Cross-model links to other MMEL models. Optional.
10. Associated notes providing context. Optional.
11. Associated tables containing structured data. Optional.
12. Associated figures (diagrams or images). Optional.

2.3. Properties

The following table describes each process property:

2.4. Minimal process example

A minimal process requires only a name :

process InternalAudit {
  name "Internal Audit"
  actor Org
}

2.5. Fully-specified process example

The following example from the PAS 2060 carbon neutrality model shows a process with all property types bound:

process ExcludeEmissionSource {
  name "Exclude emission source"
  actor entity
  modality MAY
  validate_provision {
    Provision45
    Provision48
    Provision98
    Provision99
  }
  validate_measurement {
    "[Excluded_Emission].max / [Total_Emission] < 0.01"
  }
  output {
    Subject
  }
}

This process:

• is performed by the entity role
• has an obligation level of MAY (it is optional)
• must satisfy four compliance provisions
• must meet the measurement expression that no single excluded emission source exceeds 1% of total emissions
• outputs to the Subject data registry

2.6. Process with subprocess reference

When a process has a detailed flow diagram, it references a child subprocess:

process DetermineSubject {
  name "Determine subject of carbon neutrality"
  actor entity
  modality SHALL
  validate_provision {
    Provision1
  }
  output {
    Subject
  }
  subprocess Page0
}

The subprocess Page0 declaration links this process to a subprocess definition (named Page0 ) that contains the detailed flow diagram with elements, edges, and data store placements.

2.7. Process with data register I/O

Processes interact with data registers through output and reference_data_registry properties:

process DetermineScope {
  name "Determining the scope of the information security management system"
  actor Org
  modality SHALL
  reference_data_registry {
    PartyRequirement
    Issues
  }
  validate_provision {
    Provision2
    Provision6
    Provision7
  }
  output {
    Scope
  }
}

This process reads from two data registries ( PartyRequirement and Issues ) and writes to one ( Scope ).

2.8. Process with table and figure references

Processes may reference tabular data and embedded figures from the normative document:

process GeneralRequirementsForRiskManagement {
  name "General requirements for risk management"
  actor Manufacturer
  validate_provision {
    Provision7
  }
  note {
    Note1
    Note2
  }
  figure {
    Figure1
  }
  subprocess Page1
}

process RatedVoltage {
  name "Rated voltage"
  validate_provision {
    Provision1
    Provision2
    Provision3
  }
  table {
    PermittedVoltages
  }
  subprocess Page1
}

process Embossing {
  name "Embossing or indenting"
  validate_provision {
    Provision49
    Provision50
    Provision51
    Provision53
  }
  note {
    Note26
  }
  figure {
    sheathExample
    videodemo
  }
}

2.9. Process with cross-model links

Processes may reference external models via the links property:

process ProductionAndPostProductionInformation {
  name "Production and post-production information"
  actor Manufacturer
  validate_provision {
    Provision5
    Provision84
  }
  links {
    Link2
  }
  note {
    Note37
    Note38
  }
  output {
    Post-ProductionEvaluationResult
  }
  subprocess Page15
}

2.10. Process reuse mechanism

A process definition is declared once at the top level of the model but can appear in multiple subprocess diagrams. When the same process ID is placed in the elements section of multiple subprocesses, all instances share the same definition.

For example, in the BS 16341 model, the process SelectStandardC is defined once:

process SelectStandardC {
  name "Select standards in the order of preference C"
  actor Purchaser
  modality SHALL
  validate_provision {
    PreferenceOrderC
  }
}

This process is placed in the root subprocess diagram and connected to other elements via edges. Because the definition is shared, any change to the process properties is reflected in every diagram that includes it.

3.1. General

Events control the lifecycle and timing of process flows within subprocess diagrams. MMEL supports four types of events: start events, end events, timer events, and signal catch events.

Events are placed in the elements section of a subprocess and connected to other elements via process flow edges.

3.2. Start events

Start events mark the beginning of a process flow within a subprocess. Each subprocess diagram typically contains one start event.

start_event <EventID> {
}

start_event Start1 {
}
start_event Start0 {
}

subprocess Page0 {
  elements {
    Start0 {
      x -120
      y -510
    }
    DetermineSubject {
      x -105
      y -360
    }
  }
  process_flow {
    Edge0 {
      from Start0
      to DetermineSubject
    }
  }
}

3.3. End events

End events mark the termination of a process flow. They are optional; not all subprocess diagrams require an explicit end event.

end_event <EventID> {
}

end_event EndEvent {
}
end_event EndEvent1 {
}

3.4. Timer events

Timer events represent temporal conditions within a process flow. They can introduce delays, deadlines, or periodic triggers.

timer_event <EventID> {
  type WAIT | REPEAT | DURATION
  para "description"
}

timer_event TimerEvent0 {
}

timer_event TimerEvent1 {
  type WAIT
  para "at most 12 months"
}

timer_event EventCreditRetirementTimer {
  type WAIT
  para "at most 36 months"
}

timer_event NonEventCreditRetirementTimer {
  type WAIT
  para "at most 12 months"
}

timer_event RiskManagementReviewInterval {
  type WAIT
  para "Planned interval"
}

timer_event AssessmentTimer {
  type REPEAT
  para "Planned intervals or when significant changes occur"
}
timer_event AuditTimer {
  type REPEAT
  para "Planned intervals"
}
timer_event ManagementReviewTimer {
  type REPEAT
  para "Planned intervals"
}

timer_event CompetenceReviewTimer {
  type DURATION
}
timer_event AuditTimer {
  type DURATION
}
timer_event ManagementReviewTimer {
  type DURATION
}

process_flow {
  Edge61 {
    from MakeCommitment
    to TimerEvent1
  }
  Edge62 {
    from TimerEvent1
    to MakeCommitment
  }
}

process_flow {
  Edge80 {
    from ImplementPlan
    to TimerEvent2
  }
  Edge65 {
    from TimerEvent2
    to PeriodicAssessment
  }
}

3.5. Signal catch events

Signal catch events are intermediate events that pause process execution until a named signal is received from another part of the model or an external source.

signal_catch_event <EventID> {
  catch "<signal-name>"
}

signal_catch_event EditionUpdated {
  catch "StandardDataRegistryUpdated"
}

process_flow {
  Edge3 {
    from EditionUpdated
    to DifficultyGateway
  }
}

4.1. General

Gateways are decision points in a process flow where the path diverges. MMEL supports exclusive gateways, where exactly one outgoing path is taken.

4.2. Exclusive gateway syntax

exclusive_gateway <GatewayID> {
  label "Decision question?"
}

The label property contains the decision question or condition that determines which outgoing path is taken. The label is optional; gateways without a label are valid.

4.3. Edge descriptions for branching paths

Gateway branching is expressed through the description property on outgoing edges. Each outgoing edge from a gateway carries a description that labels the decision path:

Edge47 {
  from NATOGateway
  to SelectStandardB
  description "Yes"
}
Edge48 {
  from NATOGateway
  to SelectStandardC
  description "No"
}

4.4. Default branch

The string ” default “ as the edge description marks the default fallback path from a gateway. When none of the explicit conditions match, the default path is taken:

Edge28 {
  from NeutralityGateway
  to MakeCommitment
  description "default"
}

An edge with description "default" and condition "default" is the default branch:

Edge47 {
  from SingleSourceDominanceGateway
  to ApplyOverallCoverageRule
  description "default"
  condition "default"
}

4.5. Gateway without conditions

When a gateway has multiple outgoing edges without explicit condition expressions, the flow is fulfilled if any one of the outgoing paths is fulfilled. The description field provides a human-readable label for each branch, but the actual branching decision may be determined by the tool or runtime based on the process context.

Example from the BS 16341 model:

exclusive_gateway NATOGateway {
  label "Is it for NATO nations: some standards are ratified (without reservations) with the intention of implementation for e.g. achieving the required interoperability between forces?"
}

With branching edges:

Edge47 {
  from NATOGateway
  to SelectStandardB
  description "Yes"
}
Edge48 {
  from NATOGateway
  to SelectStandardC
  description "No"
}

4.6. Gateway with measurement expression conditions

Gateways may have outgoing edges with condition expressions that contain measurement-based guards. The condition is a string expression evaluated against measurement values to determine which path is taken.

Example from the PAS 2060 model with the Single Source Dominance gateway:

exclusive_gateway SingleSourceDominanceGateway {
  label "Does a single source contribute more than 50% of the total emissions"
}

With condition-guarded edges:

Edge46 {
  from SingleSourceDominanceGateway
  to AlternativeCoverageValidation
  description "A single source contributes more than 50% of the total emissions"
  condition "[Largest_Emission_In_Percentage] > 0.5"
}
Edge47 {
  from SingleSourceDominanceGateway
  to ApplyOverallCoverageRule
  description "default"
  condition "default"
}

When [Largest_Emission_In_Percentage] exceeds 0.5 (50%), the alternative coverage validation path is taken. Otherwise, the default overall coverage rule path applies.

Example from the BS 13485 medical devices model:

exclusive_gateway SterileMedicalDevicesGateway {
  label "Sterile medical devices?"
}

With condition-guarded edges:

Edge3 {
  from SterileMedicalDevicesGateway
  to EndEvent2
  description "no"
  condition "default"
}
Edge4 {
  from SterileMedicalDevicesGateway
  to DocumentRequirementsForContamination
  description "Yes"
  condition "[sterile] = 'true'"
}

When the [sterile] measurement is ’ true ‘ , the path to contamination control documentation is taken. Otherwise, the default path leads to the end event.

4.7. Gateway examples

exclusive_gateway NeutralityGateway {
  label "Has carbon neutrality been achieved?"
}
exclusive_gateway SubjectChangeGateway {
  label "Any material change to the subject?"
}
exclusive_gateway CalculationGateway {
  label "Is quantification based on calculations?"
}
exclusive_gateway GovernmentFactorAvailable {
  label "Are factors from national (Government) publications available"
}
exclusive_gateway RecurringEventGateway {
  label "Is the subject a non-recurring event such as a wedding or concert?"
}
exclusive_gateway HistoricReductionGateway {
  label "Are historic reductions from the defined subject, not otherwise taken into account, to be taken into account?"
}

exclusive_gateway NATOGateway {
  label "Is it for NATO nations: some standards are ratified (without reservations) with the intention of implementation for e.g. achieving the required interoperability between forces?"
}
exclusive_gateway ConstructionGateway {
  label "Is the purchaser in construction sector or some standards are related to European Technical Approvals (ETA)?"
}
exclusive_gateway NoSuitableGateway {
  label "For the present application no suitable standards or standard-like documents are available (up to this process)?"
}
exclusive_gateway RequirementMetGateway {
  label "The necessary requirements cannot be met by the application of the aforementioned standards or standard-like documents"
}

exclusive_gateway OutsourcingGateway {
  label "Outsourcing of process?"
}
exclusive_gateway SterileMedicalDevicesGateway {
  label "Sterile medical devices?"
}
exclusive_gateway NonFulfillmentGateway {
  label "Any non-fulfilment of requirements?"
}
exclusive_gateway ChangeValidationGateway {
  label "Validation required?"
}

exclusive_gateway ProcessChangeGateway {
  label "Have a change to the process"
}
exclusive_gateway AdverseEffectGateway {
  label "Any adverse effects of the change?"
}

4.8. Gateways without labels

A gateway without a label property is valid and acts as a routing point where the branching logic is determined solely by the edge conditions:

exclusive_gateway EGate1 {
}

5.1. General

Subprocesses are the primary organizational containers in MMEL. They define process flow diagrams with positioned elements, flow edges, and data store placements. Each subprocess represents a visual diagram within the model.

5.2. Syntax

subprocess <SubprocessID> {
  elements {
    <ElementID> {
      x <integer>
      y <integer>
    }
  }
  process_flow {
    Edge<EdgeNumber> {
      from <SourceElementID>
      to <TargetElementID>
      description "Branch label"
      condition "<condition expr>"
    }
  }
  data {
    <DataRegistryID> {
      x <integer>
      y <integer>
    }
  }
}

1. Elements section: lists all elements placed in this diagram with their coordinates.
2. Process flow section: defines directed edges connecting elements.
3. Data section: positions data registry stores on the diagram.

All three sections ( elements , process_flow , data ) are optional.

5.3. Elements section

The elements section lists all nodes placed in the subprocess diagram. Each element is identified by its ID (which references a top-level declaration) and has x and y coordinates for visual positioning.

The following element types can be placed in a subprocess:

Example of an elements section:

elements {
  Start0 {
    x -120
    y -510
  }
  DetermineSubject {
    x -105
    y -360
  }
  NeutralityGateway {
    x -60
    y 600
  }
  Declaration {
    x -120
    y 750
  }
  EndEvent0 {
    x -200
    y 900
  }
}

5.4. Process flow section

The process_flow section defines directed edges connecting elements. Each edge has a from and to field referencing element IDs, and optional description and condition fields.

See process-flow-edges for a full specification of edge types and patterns.

5.5. Data section

The data section positions data registry stores on the diagram. Each entry references a data_registry ID with x and y coordinates:

data {
  CarbonFootprintPlan {
    x 375
    y 870
  }
  Achievement {
    x 495
    y 870
  }
  Subject {
    x 615
    y 870
  }
}

Data registry placements do not affect the process flow logic but provide visual context for where data is stored relative to the process elements.

5.6. Example: PAS 2060 root subprocess

The following is the root subprocess from the PAS 2060 carbon neutrality model, showing the main process flow:

subprocess root {
  elements {
    Start0 {
      x -120
      y -510
    }
    DetermineSubject {
      x -105
      y -360
    }
    QuantifyCarbon {
      x -105
      y -120
    }
    DevelopManagementPlan {
      x -105
      y 150
    }
    Action {
      x -105
      y 255
    }
    Requantify {
      x -105
      y 375
    }
    BalanceOut {
      x -105
      y 480
    }
    Declaration {
      x -120
      y 750
    }
    NeutralityGateway {
      x -60
      y 600
    }
    MakeCommitment {
      x -105
      y 45
    }
    TimerEvent1 {
      x -180
      y -90
    }
  }
  process_flow {
    Edge0 {
      from Start0
      to DetermineSubject
    }
    Edge3 {
      from DevelopManagementPlan
      to Action
    }
    Edge4 {
      from Action
      to Requantify
    }
    Edge5 {
      from Requantify
      to BalanceOut
    }
    Edge6 {
      from BalanceOut
      to NeutralityGateway
    }
    Edge7 {
      from NeutralityGateway
      to Declaration
      description "Carbon neutrality has been achieved for the determined subject"
    }
    Edge28 {
      from NeutralityGateway
      to MakeCommitment
      description "default"
    }
    Edge29 {
      from Declaration
      to MakeCommitment
    }
    Edge30 {
      from MakeCommitment
      to DevelopManagementPlan
    }
    Edge61 {
      from MakeCommitment
      to TimerEvent1
    }
    Edge62 {
      from TimerEvent1
      to MakeCommitment
    }
  }
  data {
    CarbonFootprintPlan {
      x 375
      y 870
    }
    Subject {
      x 615
      y 870
    }
  }
}

5.7. Nested subprocesses

A subprocess may contain processes that themselves reference other subprocesses, creating a hierarchical decomposition. For example, the PAS 2060 model defines the root subprocess containing DetermineSubject and QuantifyCarbon as elements, and each of these processes has its own subprocess property pointing to a separate child subprocess:

process DetermineSubject {
  name "Determine subject of carbon neutrality"
  actor entity
  modality SHALL
  validate_provision {
    Provision1
  }
  output {
    Subject
  }
  subprocess Page0
}
process QuantifyCarbon {
  name "Quantify carbon footprint"
  actor entity
  modality SHALL
  validate_provision {
    Provision0
    Provision51
  }
  subprocess Page1
}

The child subprocesses Page0 and Page1 each contain their own elements and flows:

subprocess Page0 {
  elements {
    Start1 {
      x 0
      y -390
    }
    DetermineSubjectDetails {
      x -45
      y -285
    }
  }
  process_flow {
    Edge10 {
      from Start1
      to DetermineSubjectDetails
    }
  }
}
subprocess Page1 {
  elements {
    Start2 {
      x 30
      y -135
    }
    DetermineMethodology {
      x -30
      y -30
    }
    CalculationGateway {
      x 30
      y 90
    }
  }
  process_flow {
    Edge49 {
      from Start2
      to DetermineMethodology
    }
    Edge50 {
      from DetermineMethodology
      to CalculationGateway
    }
  }
}

This hierarchical structure enables top-down decomposition of complex processes into manageable sub-diagrams.

6.1. General

Approval steps are specialized process elements representing approval workflows. They extend the standard process concept with explicit approver designation and optional data registry storage for approval records.

6.2. Syntax

approval <ApprovalID> {
  name "Approval description"
  actor <RoleID>
  modality SHALL | SHOULD | MAY | CAN | MUST
  approve_by <RoleID>
  approval_record {
    <DataRegistryID>
  }
  reference {
    <ReferenceID>
  }
}

1. Display name describing the approval. Required.
2. The role initiating the approval request. Optional.
3. The modality/obligation level of the approval. Optional.
4. The role that grants approval. Required for meaningful approval workflows.
5. Data registry where the approval record is stored. Optional.
6. Normative references supporting this approval. Optional.

6.3. Properties

6.4. Approval record for data registry storage

The approval_record property specifies the data registry where the resulting approval record is stored. This enables tracking which approvals have been granted, by whom, and when.

When an approval is granted, a record is written to the specified data registry, creating an auditable trail of approval decisions.

6.5. Examples

approval Approval1 {
  name "Approve data protection policies"
  actor Organisation
  modality SHALL
  approve_by Management
  reference {
    DPTM-doc-doc-ref1-1-1
  }
}

approval Approval2 {
  name "Obtain management approval"
  actor Organisation
  modality SHALL
  approve_by Management
}

approval OnwerApproval {
  name "Obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks"
  actor Org
  modality SHALL
  approve_by Owner
  reference {
    ref6-1-3
  }
}

approval NonApplicationApprove {
  name "Non-application of a standard requires the Purchaser's written approval"
  actor Contractor
  modality SHALL
  approve_by Purchaser
  approval_record {
    StandardApprovalDataRegistry
  }
  reference {
    Ref41
  }
}

data_registry StandardApprovalDataRegistry {
  title "Approval of non-application of a standard"
  data_class StandardApprovalData
}
class StandardApprovalData {
  standard: reference(StandardData) {
    definition "Standard"
    modality SHALL
    reference {
      Ref41
    }
  }
  approval {
    definition "A written approval"
    modality SHALL
    reference {
      Ref41
    }
  }
}

6.6. Approvals in process flows

Approvals are placed in subprocess diagrams as elements, just like processes. They participate in the process flow via edges:

subprocess Page0 {
  elements {
    NonApplicationApprove {
      x -1110
      y 450
    }
  }
  process_flow {
    Edge83 {
      from NonapplcationGateway
      to NonApplicationApprove
      description "Yes"
    }
    Edge85 {
      from NonApplicationApprove
      to AgreeStandardProcess
    }
  }
}

7.1. General

Process flow edges are directed connections between elements in a subprocess diagram. They define the sequence and conditions of the process flow.

7.2. Edge syntax

Edge<EdgeNumber> {
  from <SourceElementID>
  to <TargetElementID>
  description "Branch label"
  condition "<condition expression>"
}

1. Source element ID. Required.
2. Target element ID. Required.
3. Human-readable label for the edge. Optional. Used primarily for gateway branching paths.
4. Condition expression for gateway branching. Optional. The string ” default “ marks the default fallback path.

Edge numbers are unique within a subprocess's process_flow section but need not be sequential.

7.3. Serial connections

The most common edge pattern is a serial connection, where one element flows directly to the next:

Edge0 {
  from Start0
  to DetermineSubject
}
Edge1 {
  from DetermineSubject
  to SelectMethodologies
}
Edge8 {
  from SelectMethodologies
  to QuantifyCarbon
}

Serial edges have no description or condition fields. They simply define the sequence of execution.

7.4. Parallel connections

When a source element has multiple outgoing edges without conditions, both target elements are activated. There is no guaranteed order between them; both are required:

Edge77 {
  from Start0
  to IdentifyStandardProcess
}
Edge13 {
  from Start0
  to Documentation
}
Edge25 {
  from Start0
  to DeterminePeriod
}

In this example, the start event connects to three elements in parallel. All three are triggered simultaneously.

7.5. Self connections (repeated execution)

A self connection occurs when a process connects to a timer event and the timer connects back to the same process, creating a repeating cycle:

Edge61 {
  from MakeCommitment
  to TimerEvent1
}
Edge62 {
  from TimerEvent1
  to MakeCommitment
}

This pattern creates a loop where:

1. The MakeCommitment process triggers the TimerEvent1 timer
2. When the timer fires (after the specified wait period), the flow returns to MakeCommitment
3. The cycle repeats

Another self-connection pattern with an intermediate process:

Edge80 {
  from ImplementPlan
  to TimerEvent2
}
Edge65 {
  from TimerEvent2
  to PeriodicAssessment
}
Edge66 {
  from PeriodicAssessment
  to ImplementAction
}
Edge68 {
  from ImplementAction
  to ImplementPlan
}

This creates a loop: ImplementPlan -> TimerEvent2 -> PeriodicAssessment -> ImplementAction -> ImplementPlan.

7.6. Gateway branching with conditions

Gateway branching uses edges with description and optionally condition fields to define the decision paths:

Edge47 {
  from NATOGateway
  to SelectStandardB
  description "Yes"
}
Edge48 {
  from NATOGateway
  to SelectStandardC
  description "No"
}

Edge34 {
  from SubjectChangeGateway
  to EndEvent3
  description "default"
}
Edge35 {
  from SubjectChangeGateway
  to Restart
  description "Material change to the subject occurs"
}

Edge46 {
  from SingleSourceDominanceGateway
  to AlternativeCoverageValidation
  description "A single source contributes more than 50% of the total emissions"
  condition "[Largest_Emission_In_Percentage] > 0.5"
}
Edge47 {
  from SingleSourceDominanceGateway
  to ApplyOverallCoverageRule
  description "default"
  condition "default"
}

Edge3 {
  from SterileMedicalDevicesGateway
  to EndEvent2
  description "no"
  condition "default"
}
Edge4 {
  from SterileMedicalDevicesGateway
  to DocumentRequirementsForContamination
  description "Yes"
  condition "[sterile] = 'true'"
}

7.7. Edge condition expressions

Edge conditions may contain:

• Measurement references -- [MeasurementID] references a measurement value
• Aggregation operators -- .max, .min, .sum for DATALIST measurements
• Arithmetic operators -- +, -, *, /
• Comparison operators -- <, <=, >, >=, =
• String literals -- ’ true ‘ , ’ false ‘ for boolean comparisons
• The keyword default -- marks the default fallback path

Examples of edge condition expressions:

8.1. Process declarations

ProcessDecl     ::= 'process' IDENTIFIER '{' ProcessField* '}'
ProcessField    ::= 'name' STRING
                  | 'actor' IDENTIFIER
                  | 'modality' MODALITY
                  | 'validate_provision' '{' IDENTIFIER* '}'
                  | 'validate_measurement' '{' STRING* '}'
                  | 'output' '{' IDENTIFIER* '}'
                  | 'reference_data_registry' '{' IDENTIFIER* '}'
                  | 'subprocess' IDENTIFIER
                  | 'links' '{' IDENTIFIER* '}'
                  | 'note' '{' IDENTIFIER* '}'
                  | 'table' '{' IDENTIFIER* '}'
                  | 'figure' '{' IDENTIFIER* '}'

8.2. Event declarations

StartEventDecl  ::= 'start_event' IDENTIFIER '{' '}'
EndEventDecl    ::= 'end_event' IDENTIFIER '{' '}'
TimerEventDecl  ::= 'timer_event' IDENTIFIER '{' TimerField* '}'
TimerField      ::= 'type' TIMER_TYPE
                  | 'para' STRING
TIMER_TYPE      ::= 'WAIT' | 'REPEAT' | 'DURATION'
SignalCatchEventDecl ::= 'signal_catch_event' IDENTIFIER '{'
                         'catch' STRING '}'

8.3. Gateway declarations

GatewayDecl     ::= 'exclusive_gateway' IDENTIFIER '{'
                     ('label' STRING)? '}'

8.4. Approval declarations

ApprovalDecl    ::= 'approval' IDENTIFIER '{' ApprovalField* '}'
ApprovalField   ::= 'name' STRING
                  | 'actor' IDENTIFIER
                  | 'modality' MODALITY
                  | 'approve_by' IDENTIFIER
                  | 'approval_record' '{' IDENTIFIER* '}'
                  | 'reference' '{' IDENTIFIER* '}'

8.5. Subprocess declarations

SubprocessDecl  ::= 'subprocess' IDENTIFIER '{'
                     ElementsSection? FlowSection? DataSection? '}'
ElementsSection ::= 'elements' '{' ElementDecl* '}'
ElementDecl     ::= IDENTIFIER '{' 'x' NUMBER 'y' NUMBER '}'
FlowSection     ::= 'process_flow' '{' EdgeDecl* '}'
EdgeDecl        ::= 'Edge' INTEGER '{'
                     'from' IDENTIFIER 'to' IDENTIFIER
                     ('description' STRING)?
                     ('condition' STRING)? '}'
DataSection     ::= 'data' '{' DataPosDecl* '}'
DataPosDecl     ::= IDENTIFIER '{' 'x' NUMBER 'y' NUMBER '}'

8.6. Common tokens

MODALITY        ::= 'SHALL' | 'SHOULD' | 'MAY' | 'CAN' | 'MUST'
STRING          ::= '"' ... '"'
IDENTIFIER      ::= [a-zA-Z_][a-zA-Z0-9_'-]*
INTEGER         ::= [0-9]+
NUMBER          ::= ('-')? [0-9]+ ('.' [0-9]+)?

8.7. Complete process model declaration

A process model consists of declarations that can appear at the top level of an MMEL file, intermixed with data modelling, compliance, measurement, and cross-model declarations:

ProcessModelDecl ::= ProcessDecl
                   | StartEventDecl
                   | EndEventDecl
                   | TimerEventDecl
                   | SignalCatchEventDecl
                   | GatewayDecl
                   | ApprovalDecl
                   | SubprocessDecl