Page tree
Skip to end of metadata
Go to start of metadata

Read the Instructions.

If your MP model is a homework assignment or for a class project, read the assignment instructions carefully.  If, for example, the assignment requires you to demonstrate all event patterns, make sure you have all event patterns in your submission. Attention to details is the foundation of modeling business.

Beware of Copy/Paste Errors.

Sometimes it makes sense to copy/paste from, or directly edit, an existing MP model to create a new MP model, rather than start a new MP model from scratch.   In this case, make sure that you remove all irrelevant comments from the new model. Wrong comments are dangerous!

Commenting Guidance

Provide an Accurate Model Introduction.

Always begin every model with some introductory comments.  Include at least the model name, author, date, and a short description of the task.


created 2017-04-14 by J.Doe

Provide a brief description of the model purpose, and how to use it.

Also include any interesting analysis highlights or results.


Naming Conventions

MP is case sensitive.  In all cases, use an underscore to separate words of the phrase. This is not required by MP, but is strongly suggested.  Use of CamelCase is not recommended.

Application of these conventions may seem like a waste of time at first, but it is not.  Standard conventions greatly increase the speed of comprehension and provide structure to minimize ambiguity in natural language.  Whatever the naming conventions you use, consistency is paramount.

MP Keywords

MP keywords are UPPERCASE in most instances with a few exceptions.  (Refer to keywords listing in Section 7 of the MP manual). Therefore usage of ALL_CAPS is not recommended in order to avoid confusion.

Naming Events

Most events in a model are usually activities, but some high level (composite) events can be equated with components, processes, states, and even time phases.  

One can use good language grammar to help a reader decipher which type of these event types you are representing:

  • Choose a noun-oriented name for an event that represents a thing, component, object, system, person, or organization (e.g., Operations_Team, UAV).  Use title case for capitalization.
  • Choose an imperative present-tense verb or verb phrase for an event name that represents an activity (e.g., Provide_command, Analyze_object).  Use sentence case for capitalization.
  • You may choose an indicative past-tense verb or verb phrase to represent zero-duration or instantaneous events (e.g., Authorization_received, Object_detected).  Use sentence case for capitalization.
  • Choose an indicative present continuous verb or verb phrase for an event name that represents a state (e.g., Conducting_Maintenance, Powering_Up).  Use title case for capitalization.
  • Choose a process-oriented phrase for an event name that represents a process or time phase (e.g., Mission_Preparation, On_Station).  Use title case for capitalization.

Composite Events

Composite events, such as a root event, are often named for the component that embodies the event pattern listed on the right hand side of its grammar rule.  Composite events may also be named for high level processes that contain a sequence of events, or for time phases that contain a sequence of events. 

One Event Per Line (in General).

Try to write one event per line.   Very long lines can be continued  (there is no special line continuation character).

Use Indentation and Blank Lines.

Use indentation and blank lines to make the MP code more readable, and to help readers follow the top to bottom stream of events. This practice will become very critical when the size of the MP model starts to grow.  Indent composite event patterns, like alternative, iteration, set, to show the hierarchy.  Use blank lines to separate composite event definitions.

Use Commas inside Set Patterns for Concurrency.

Use commas in the event set patterns if you want to make events concurrent.   Commas are syntactically significant.  Refer to Section 5.8 of the MP Guide.

  • No labels


  1. Use Commas inside Set Patterns for Concurrency.

    Use commas in the event set patterns if you want to make events concurrent.


    I don't know whether the commas are part of the language or are style guidance.  Section 5.8 (58) seems to imply from the color coding that the comma is part of the syntax rather than being a style convention.  Section 5.3 (17) shows a comma which also implies (along with the color coding) that it is part of the syntax, however the word concurrent is not mentioned in that section.

    1. I think Prof. Auguston's rationale for including this was that students were not using commas when it looked like they probably should have been to convey their intended meaning.  At a minimum this should be elaborated with maybe some examples, and maybe the style guide is not the place to do that.  Auguston, Mikhail (CIV), what are your thoughts?

  2. Yes comma is an element of MP language syntax. It has a strong meaning:


    Unknown macro: { a b, c d }

    " means that sequence a b can be concurrent with sequence c d, when "

    Unknown macro: { a, b, c, d }

    " means that all four events a, b, c, d may be concurrent.



  3. This should be in the tutorial.

  4. with regard to naming conventions: I don't see conditions addressed.   is  ALL_CAPS suggested?