Testbed-12 Aviation SBVR Engineering Report

The following use cases were discussed in detail:

The following use cases were also identified but couldn’t be discussed in detail because of time restrictions:

Though not required by the RFQ, we provided a proof of concept that existing tools for automatic SBVR translation are extendable towards the support of geo-spatial operators. We successfully extended ShapeChange and m-click.aero’s AIXM Validator, which is described in Use Case 3: Validation of an airport’s address against its geo-location.

The actual constraint is as follows: the aircraft’s landing distance shall be lesser or equal than the runway length. A look at the AIXM reveals (more detail below) that the runway length is represented as a scalar value. Hence, there is no need for a spatial calculation based on the runway geometry which means this use case does not require the application of spatial constraints (the use case of checking the runway’s geometry against the runway’s length property is a different one and wasn’t evaluated in this ER).

The figures below from the AIXM 5.1 dictionary show that airports (AirportHeliport) are linked to AircraftCharacteristic and FlightCharacteristic objects. The AircraftCharacteristic object describes a type of aircraft. However, it does not contain landing distances directly. We assume that it can be derived or calculated from the properties aircraftLandingCategory, speed and weight, and also depends on whether it is a regular landing or an emergency landing. The latter information is described in objects of type FlightCharacteristic (property status). How the calculation can be done is out of scope here. For the purpose of consistency checks, we assume that the suitability for emergency landings is not based on runway length only, but may include obstacles and the topology around the runway. Because of this, we will formulate checks for regular landings only.

The class diagram about Runway and RunwayElement show that the length of a runway is contained in RunwayElement as a scalar value. That means this check can be expressed without the extended spatial operators from [1], but with as many SBVR rules as there are values of CodeAircraftCategoryType, because for each aircraft category a different minimum required length applies.

We will begin with a rough outline of the rules and then refine them to obtain a valid SBVR rule. A first version is:

where X denotes an aircraft category ('A' through 'E'), and Y suitable length values (Please note that [5] recommends use the term 'It is prohibited that' in favor of 'It is obligatory that').

The marked parts are inexact and/or not supported yet by the existing SBVR. We will discuss and refine them now:

"[AirportHeliport] has Runway that isSituatedAt it"

where "it" refers to the aforementioned object (here: AirportHeliport). Further evaluation of this has to be deferred to future activities.

"is available for regular landing of aircraft category X"

Again, this expression is not compatible with existing SBVR vocabulary as it does not refer to the elements in AIXM. The general availability is expressed through AirportHeliportUsage.operation, which is linked to AirportHeliport through the associations 'isOperationalBy (AirportHeliportAvailability)' and 'isRegulatedBy (AirportHeliportUsage)'. Further, AirportHeliportUsage.type is expressed if the described usage is permitted or forbidden (and more). Now we have:

The first ellipsis "[…​](1)" stands for the part where additional constraints on the PropertiesWithSchedule object have to be set from which AirportHeliportAvailability is derived. This falls in the category 'dealing with the current state' in SBVR, which is discussed in a separate chapter (Chapter 10). For the further analysis we assume that the suggested solution presented there is applied, which moves the evaluation of the current state outside the SBVR rule.

The second ellipsis "[…​](2)" stands for the part where the AircraftCharacteristic and FlightCharacteristic objects are identified. These objects are linked to AirportHeliportUsage by an object of type ConditionCombination, with which simple logical expressions can be built. As can be seen in Figure 3, the logical expressions are combinations of AircraftCharacteristic, FlightCharacteristic and Meteorology, which are linked through boolean operators ("and", "or", "not" etc.). We need to express the constraint "logical expression (ConditionCombination) matches AircraftCharacteristic with aircraftLandingCategory Y and FlightCharacteristic with status 'ALL'". It is obvious that it is not feasible to formulate this with first order logical connectives only. What is needed is a new predicate to express that (e.g. "matches").

The refined rule is:

Discussion:

In order to formulate this rule, SBVR for AIXM needs

However, the example shows that the resulting rule is very complex and hard to be read by humans. The main causes for this are

Furthermore, we observe that there are ambiguities in the rules that have to be resolved. If two constraints, formulated on properties that are accessed through the dot operator ("."), share an ancestor path, and that ancestor path contains multiplicities greater than one, it is unclear whether both constraints refer to the same or different ancestor. In the rule above, this problem is visible in the expression:

availability.AirportHeliportAvailability.usage.AirportHeliportUsage.operation equal-to ('ALL', 'LANDING') and availability.AirportHeliportAvailability.usage.AirportHeliportUsage.type equal-to ('PERMIT','RESERV')

Multiple AirportHeliportUsage objects can be associated with AirportHeliportAvailability. Here, the constraint intends to express that at least one AirportHeliportUsage.usage object exists that at the same time fulfills operation equal-to ('ALL', 'LANDING') and type equal-to ('PERMIT','RESERV'). But it could also be read in a way that it only requires that one usage fulfills operation equal-to ('ALL', 'LANDING') and another one type equal-to ('PERMIT','RESERV'). This ambiguity can also be found in some rules of [5]. A possible solution is the introduction of variables.

For this use case in a validation scenario, the constraint on the runway that was formulated in Landing Distances and Runways has to change, but the remaining constraints on the airport stay the same. The objective is to check whether the risk of overshooting the last taxiway is acceptable for the permitted aircraft types and flight status (regular or emergency landing). We assume that this risk is directly related to the distance of the last taxiway from the start of its runway.

In order to determine that distance, the spatial relation of all adjacent taxiways has to be analyzed. As seen in Figure 4, in AIXM, Taxiway features consist of a number of TaxiwayElement features which in turn contain a geometry (a surface). Taxiways do have properties for width and length, but no property for their spatial distance to the end (or start) of an adjacent runway. Hence, that value has to be calculated by a spatial distance operation taking two geometry objects as operands (see Figure 2 and Figure 4):

Please note that ← denotes a reverse association, e.g. that TaxiwayElement contains an association to Taxiway.

The next step is to find a link between taxiways and runways. There are two options:

As Figure 5 shows, an association path from Taxiway to Runway is given via the objects RunwayDirection, RunwayCentrelinePoint and GuidanceLine.

For the spatial calculation, the extents of all RunwayElement objects linked through association describesPartOf to Runway have to be considered.

We choose the spatial calculation, as this the topic of the section. This gives us:

Where the parts in square brackets stand for

It isn’t possible to further refine the constraint with the present vocabulary and grammar. To refine (2), we need a possibility to combine an quantification and a navigation. For (3), we need an identifier for reference.

The problems of navigating through the complex model with SBVR and formulating complex constraints between different elements of it have been sufficiently covered by the use cases above. Here, we focus on the spatial constraint instead.

The turning radius of an aircraft might be too big for the aircraft to operate on a taxiway describing a curve. The validation needs to check whether the minimum radius of some part of a taxiway is bigger than an acceptable value. Figure 6 shows that Taxiway objects are connected to GuidanceLine objects which contain a geometry object of type ElevatedCurve. A curve geometry in GML is made up of segments, where each segment can either be

If all segments would be types of arcs with a radius property such as ArcByCentrePoint, the constraint will be

each extent.ElevatedCurve.segments.ArcByCenterPoint.radius is-greater-than X

However, in the general case a combination of straight and curved elements are likely, where the connection points of two segments constitute a singularity regarding the required turning radius. To get a realistic constraint, some sort of smoothing of the guidance line has to be applied in advance, and the minimum radius derived from it. This complex operation cannot be described with existing spatial operators. A new specialized spatial operator has to be introduced.

Identification of airports along the flight trajectory is necessary to comply with Extended Operations (ETOPS) rules for emergency landings.

Trajectories of concrete flights are not found in AIXM, which defines static data, but in FIXM. In order to provide a stable validation rule, it is important that flight data from FIXM can be unambiguously linked to corresponding AIXM data. However, this is not provided in the current version of FIXM, V3.0.1, in which for example airports are referenced by their name only. For a stable resolvable link to AIXM, their unique identifiers (gml:identifier UUIDs) have to be provided. This is one of the topics discussed for the next version of FIXM in this testbed (see [9]).

For this use case, we therefore assume that the trajectory is given as a list of geo-locations starting at the departure airport and ending at the destination airport (or alternate).

The objective: check if suitable emergency airports are in acceptable reach at every time of the flight, taking into applicable ETOPS rules. The ETOPS rules define a maximum distance to the next suitable airport suitable for emergency landing, depending on the type of the aircraft. The determination of that distance from the aircraft type is not considered here, as we want to focus on the geo-spatial constraints that are involved. An example is shown in Figure 7.

A pseudo algorithm for this could be formulated as follows:

SBVR rules have to be formulated in one sentence. We did not find a way to accomplish that. A first draft could look like this:

The complexity lies in the last part, where a geometry has to be constructed as a union of several other geometries fulfilling certain constraints. Unfortunately, SBVR does not support any geometry construction yet, and neither depending on its constituents on elements in the rule (here "the flight route", i.e. a list of geo-locations connecting the departure with the destination airport). Even if that might be possible in a future version of SBVR for AIXM, the restriction that a rule is formulated in a single sentence impedes the readability. Instead, for rules with such a complexity, the breakdown in smaller "steps", as in the pseudo algorithm example, is preferred.

The creation of a flight plan involves the identification of suitable features. This is different from a validation scenario, where existing data is checked for consistency. These differences, and how they can be supported by SBVR, is covered in Filtering Data Using SBVR. Regarding the actual SBVR expressions involved, refer to Flight plan validation above.

The SBVR implementation of ShapeChange follows a three step process:

Changes and extensions had to be applied on each of the steps:

The result is Schematron code enriched with custom XPath functions, which were implemented by m-click.aero’s AIXM Validator Service.

m-click.aero’s AIXM Validator Service uses a custom Schematron implementation to allow for more flexibility than common XSLT-based implementations. The main work was done in the embedded XPath 2.0 engine, which had to be extended by custom XPath functions for spatial operations. Multiple types of operands had to be supported:

The following spatial operators were implemented:

The proof of concept was successfully made: the implementation path set by the toolset ShapeChange + m-click.aero’s AIXM Validator Service is extendable to support spatial operators. Despite the complexity of the task, where several intermediate levels and representations were affected, the extension towards the application of custom XPath functions is promising for future enhancements, as they give a lot of power and flexibility.

With this approach, any SBVR rule might be used as a filter, and it should work with any SBVR processor. However, it is inefficient, because the complete set of features (perhaps initially filtered by type) is processed twice.

All SBVR rules contain a filter expression which has to be evaluated by the SBVR processor. If only the filter expression is used, and if the sub-module of an SBVR processor interpreting that expression could be isolated, an efficient condition-based identification of features in a human-friendly language is possible.

In the context of Web Feature Services [7], such "SBVR filter expressions" could be used as an alternative to filters based on the Filter Encoding Implementation Specification [8].