Date: Fri, 29 Mar 2024 07:52:13 +0000 (UTC) Message-ID: <369648149.16894.1711698733634@pmtpub41.ops.cfmu.eurocontrol.be> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16893_107931620.1711698733634" ------=_Part_16893_107931620.1711698733634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The AIXM UML model defines, using UML class di=
agrams, the information items that are in the scope of the "aeronautical in=
formation" domain. This includes definitions of classes, attributes and rel=
ationships between classes. For attributes, constraints expressed as lists of values, range of values, pattern are also incl=
uded in the AIXM UML model. The AIXM XML schema is derived from the U=
ML model and defines elements that correspond to the AIXM model classes, at=
tributes and association role names. The values of XML elements and data ty=
pes derived from UML attributes are constrained based on the data types def=
ined in the UML model - list of values, data ranges and/or patterns.
More complex constraints, such as dependencies between the v= alues of different attributes (sometimes in different classes= ), detection of 'out of range' values, mandatory properties for class of ob= jects, etc. are not included in the AIXM UML model and do not appear in the= XML Schema. Thus, there is need to document such more complex constraints = as "business rules". The aim of providing AIXM Business Rules is to be able= to define what is possible or allowed in an AIXM data set, in = particular with regard to data values.
Not all the AIXM Business Rules are equally ap= plicable in all communities of AIXM users. The most obvious example are man= datory properties for AIXM features - in a flight planning community, there= is no need to include in an AIXM data set the frequency/channel of a navig= ation aid. On the other side, such attributes are mandatory for data sets p= rovided to an air navigation community. Therefore, the aim of the AIXM Busi= ness Rules is to document an exhaustive pool of rules, from which profiles = for a particular community can be extracted. This includes requirements for= minimal data properties, data qualit= y and any other operational constraints<= /em>, such as the rules for frequency pairing for VHF navaids, etc. This al= so includes structural rules that are specific to the AIXM cont= ext (such as the relation between the type of TimeSlice and i= ts validity period, etc.) and which are not enforceable with the AIXM XML s= chema.
An AIXM Business Rules Profile was defined for the data input to the European AIS Database (EAD= ). Additional profiles are being defined for the ICAO digital data sets (AI= P, obstacles, etc.) and for Digital NOTAM.
The initial approach for the AIXM 5.x business rules was based on&= nbsp;SBVR= as rule language and on the AIXM UML model as business vocabul= ary. This was applied for the provision of the AIXM Business Rules for the = European AIS Database (EAD), until end 2023. This approach is documented he= re: V= ersion 1 (until 2023)
The objective of the "new SBVR syntax" is to maximise the potential for automati= c generation of data set validation code = span>from the AIXM Business Rules. This is achieved through the following c= hanges in the AIXM Business Rules approach:
This new approach is documented here: Version 2 (starting in 2024)