Implementing a DSL for regal flight crew duty periods

Hello,

I am new to language design and DSLs and would need some advice on how to design a DSL for specifying legal duty periods for airline personnel. The aviation industry is heavily regulated and maximum duty time rules are enforced to ensure public safety.

For example, duty period rules could include:

  • 60 duty hours in any 7 consecutive days;
  • 110 duty hours in any 14 consecutive days;
  • 190 duty hours in any 28 consecutive days, spread as evenly as practicable throughout that period.

In a similar way, pilots must abide by flight duty period (FDP) limitations such as:

  • 100 hours of flight time in any 28 consecutive days
  • 900 hours of flight time in any calendar year;
  • 1,000 hours of flight time in any 12 consecutive calendar months.

In addition to maximum duty and flight time limitations, rest period rules need to be also enforced, such as:

“The minimum rest period provided before undertaking an FDP starting at home base shall be at least as long as the preceding duty period, or 12 hours, whichever is greater”

To complicate matters, each (European) airline usually has its own set of rules and regulations resulting from union agreements.

Hardcoding the aforementioned rules is not practical because the rest and duty period rules might change from one airline to another.

Therefore, one option would be to define a DSL language enabling the airline operator to specify the rules (basically valid duty periods and mandatory rest/holidays).

I would need some advice on how to design such a language. I realize my question is quite vague and generic but having pointers on how to start would be great.

Thanks!
Anwar

1 Like

Some, quite incomplete advice:

  • Take care of grouping together rules (in whatever syntax you’ve chosen for them) in a sensible, and how these interact, e.g. with rules of some (later-defined) group augmenting/amending/overruling those of other groups. E.g., the rules of an airline might overrule some of the national rules, but should still be “compatible” with those in some respect.
  • Also take care of how rules within a group might interact with each other.
  • You’ve already got an idea of the syntax, it seems, which is a good basis to start off from.
  • Think about what technology you need to integrate with.
  • Think about what the authoring process should look like?

http://dsl-course.org/ has links to the most important resources for DSLs.

There’s also many resident DSL consultants here :wink:

2 Likes

Meinte,

Thanks for your feedback which is very helpful indeed.

In practice, European regulations specify the strict minimum required for safety, but usually airline are more “strict” in the sense that they cannot create incompatible rules (this translates by shorter duty periods and longer rest/vacation periods).

Just realized that you are the author of " Domain-Specific Languages Made Easy" so I will start reading your book first :slight_smile:

Thanks,
Anwar

Hope this advice and/or the book are useful to you! Originally, the book was going to have a chapter on DSL design, but we had to cut that for space reasons. Maybe it goes in a 2nd book, or I’ll release it in some other form.

1 Like

So I have been considering using OCL (Object Constraint Language - Wikipedia) as a first step in implementing the flight duty period rules.

I see the following advantages in using OCL:

  • The ability to reuse an existing DSL used for specifying constraints, invariants and rules
  • Reuse existing OCL parsers
  • Use of a higher level language by a rules modeler which is at the same time close enough to Java (the target runtime language)
  • Easily embed OCL in my system using Java

An alternative would be to define a standalone DSL heavily inspired from OCL (in other words a minimal subset of OCL) containing only the types required for duty period validation. I would then have to write my own parser using ANTLR.

Any thoughts?

I advise you to stay as close to the domain as possible - it’s not called a Domain Specific Language for nothing. OCL has a profoundly different domain than duty regulations.

It’s tempting to reuse an existing parser, but there’s hardly any need: Xtext, MPS, ProjectIt, Langium, etc. are good enough to implement a language with your own syntax.