One of the challenges faced by network management systems is the increasing need for consistent management of physical network equipment. We propose a solution where equipment is modelled using a dedicated Domain Speci c Language (DSL) enriched with the power of logic-based reasoning services. This enables us to de ne a rich layer of semantics on top of the structural description of the devices. This way, the con guration related constraints are expressed declaratively, in a platform independent manner, and are managed in an integrated way with the structural model. The information kept in the model can then be used on runtime to give guidance to the system user.
One of the challenges faced by Next Generation Operation Support Systems
(OSS) [
In our approach, we propose a solution where equipment is modelled using a dedicated domain speci c language enriched with the power of logic-based reasoning services. This enables us to de ne a rich layer of semantics on top of the structural description of the devices. This way, the con guration related constraints are expressed declaratively, in a platform independent manner, and are managed in an integrated way with the structural model. The information kept in the model can then be used on runtime to give guidance to the system user. 2
Myriads of device types and their con gurations can make user's everyday work a nightmare. For example, each time a card in some device is broken, the system operator faces questions like, \what are the possible replacements for that card, are some options better then others?" On the other hand, a system analyst planning new services on a particular device wants to know what components he can use with that device, if possible, from those available in the company's warehouse.
Similar questions may also arise while integrating manually maintained repositories of physical network equipment. In such cases, automatic checking of device con guration correctness or even nding the exact device type using only information about its con guration, would surely improve the integrity and correctness of existing data.
Let's take an example of a usual situation in telecommunication companies when one of the physical device cards is broken or not supported any longer and requires replacement. Figure 1 presents an example con guration of the Cisco 7603 chassis. It contains two cards. The card in slot 1 is a supervisor card, required by the device to work properly. In slot 2, a backup supervisor card is inserted.
Let's suppose that the main supervisor card is broken and requires replacement. The person responsible for this device receives a noti cation about the problem and begins to resolve it. Current solutions of OSS systems require deep knowledge about every sub-component of the physical device (what kind of cards can be used as a replacement for a broken card, what kind of constraints a particular card has, etc.).
To limit the e ort required to solve such problems, we designed a DSL that describes the structure of the physical device and stores information about a possible connection between physical device elements. In our example of a simpli ed Cisco 7603 from Figure 2, we specify that it has three slots and that the rst slot is required (marked red in the diagram). The possible or required cards are indicated in blue rectangles next to the respective slots. The description can be enriched with the additional ontology axioms. One of the constraints that occur, is that the Hot Swappable OSM card require a speci c supervisor engine, namely Supervisor engine 720 in the Cisco 7603 con guration.
As shown, there is clearly a need for tools providing advanced support helping users make correct decisions, tools based on knowledge and semantics, able to reason and bring meaningful answers for user questions. The problems to address are much more broad than simply suggesting the replacements of a broken card: 1. Network planning - what components can I use with a given con guration of a device to build my service? 2. Consistency checks - is my con guration valid? 3. Data quality - what is the exact type of device, given it's con guration? 4. Explanations and guidance: Why the con guration is invalid? How can I x it?
Such tools, guiding and supporting users through tedious tasks by answering the questions mentioned, would generate substantial pro t, and reduce the number of potential errors in device con gurations. It would also improve productivity, and mitigate the time consumed studying the technical details of a device's documentation.
To achieve these goals, we follow an approach proposed by our partner in the
MOST project, the University of Koblenz-Landau 3, based on the idea of
integration of models and ontologies [
Existing works that compare the ontological and metamodelling technology
spaces [
A prototype implementation of a physical devices modelling tool was developed
using Eclipse Modelling Framework 6. The goal of the tool was to enable
modelling physical devices in a DSL and, at the same time, take advantage of formal
semantics and expressivity of OWL. In this early prototype, the integration of
the domains of models and ontologies was achieved by model transformations
speci ed in QVT Operational [
As shown in Figure 3, the prototype consists of the following artefacts:
PDDSL The Physical Devices Domain Speci c Language (PDDSL) enables
speci cation of possible con gurations of device models. The language uses
concepts related to the structure of devices: Con guration, Slot, Card.
Figure 2 gives an example of a model expressed in PDDSL. An excerpt of the
metamodel of PDDSL is given in Figure 4. The language has also a concrete
textual syntax which, for brevity, is not described in this document. Also, for
simplicity, we consider Con guration concept as the direct representation of
a physical device type, while in real scenario a device could have multiple
alternative con gurations
PDIDSL The Physical Devices Instances Domain Speci c Language (PDIDSL)
enables de nitions of concrete instances of devices that conform to the
PDDSL speci cations. An example of a PDIDSL model is given in Figure
1. As depicted in Figure 3 PDIDSL models conform to a metamodel which
is speci ed with PDDSL. However, since PDDSL is not a metamodelling
language we need an additional step, where some PDDSL model is mapped
to an Ecore metamodel. This transformation is not given here for the sake
of brievity. An excerpt of the metamodel of PDIDSL is given in Figure 5.
OWL We use OWL Manchester Syntax [
Manchester Syntax was chosen because there already exists an Ecore metamodel for it, and more importantly, generated OWL models can be serialized into valid Manchester Syntax les without the need for another transformation (as in case of Ontology Data Model) using EMFText tool 7.
OWL extensions Additional knowledge related to physical devices is de ned in OWL Manchester Syntax. Section 4.4 describes an example of such an ontology.
Reasoner We use Pellet to perform reasoning in the prototype. Examples for reasoning are given in Section 4.5.
PDDSL2OWL A QVT operational transformation transforms PDDSL models into an OWL T-box. It is further described in Secion 4.1.
PDIDSL2OWL A QVT operational transformation transforms PDIDSL models into an OWL A-box. It is further described in Secion 4.2.
In the modeling domain the languages conceptually form the following hierarchy: M3 level Ecore metametamodel M2 level PDDSL metamodel de ning the language needed to describe possible con gurations of devices M1 level PDDSL models describing the possible con gurations of a device.
PDIDSL metamodel de ning the language needed to describe concrete congurations of devices M0 level PDIDSL model represents concrete con gurations 4.1
The goal of the PDDSL2OWL transformation is to extract the OWL T-box from the PDDSL models. The transformation maps the concepts of the PDDSL into OWL classes and properties and, equally important, speci es formal semantics of the concepts from PDDSL (e.g. formalization of con guration constraints).
Figure 6 shows an excerpt of the transformation where an object property restriction is generated for the Configuration class. Each of the required slots -- configuration is mapped to subclass of Configuration -- with equivalency axiom mapping Configuration::toConfiguration() : OWL::Class { equivalentClassesDescriptions += object Conjunction { primaries += object ClassAtomic{clazz := ConfigurationClass}; -- condition on required cards primaries += self.slots [cardRequired = true]
-> map toSlotRequiredRestriction(); -- Another restrictions (not listed here): ... } in the Configuration is mapped to an ObjectPropertySome restriction on the hasSlot property. The property is restricted to a conjunction of restrictions on the hasCard property. Each of the restrictions in the conjunction speci es the required card and value restriction on the id data property indicating the slot number. 4.2
The PDIDSL2OWL transformation takes as input a model containing the instances of physical devices expressed in PDIDSL and extracts the respective OWL A-box. The transforation updates the ontology T-box produced by the PDDSL2OWL transformation by adding individuals along with the respective facts assertions. Figure 7 shows an excerpt from the transformation where an instance of Configuration is transformed into an OWL individual. The type of the individual is set to the corresponding OWL class, representing the con guration, and the respective slots are related by the hasSlot property. mapping Configuration::toConfigurationIndividual(): OWL::Individual { iri := self.name; types += object ClassAtomic { clazz := classes[iri = self.metaClassName()]
-> asSequence() -> first(); }; } };
}
self.hasSlot -> forEach (i) {
facts += object ObjectPropertyFact{
objectProperty := hasSlotProperty;
individual := i.map toSlotIndividual();
The reasoning tasks performed on models, such as consistency checking, often
require non-monotonic reasoning [
One of the means of closing knowledge is to state that a class is equivalent to an enumeration of all of its known individuals (domain closure). An update mapping that closes the world of any class with known individuals, is speci ed in Figure 8. mapping inout OWL::Class::updateClass() { self.equivalentClassesDescriptions += object IndividualsAtomic { individuals += PDmodel.objects() [metaClassName() = self.iri] .resolve().oclAsType(OWL::Individual);
The prototype allows for enriching the physical devices ontology with additional axioms, not to limit the whole solution to the expressiveness of the DSLs. Currently these axioms are speci ed in a separate OWL le that references the extracted ontology through a namespace declaration. As shown in Figure 3, to perform the reasoning tasks both OWL les automatically generated from models and manually written extension le are needed by the reasoner. The les are kept separate in order to prevent overwriting manual changes after rerunning the transformations. Figure 9 gives an example of an extension, by specifying that HotSwappable OSM cards in Cisco7603 are only allowed with Supervisor engine 720.
Namespace: pd <http://www.comarch.com/oss/pd.owl#> Ontology: <http://www.comarch.com/oss/pd-ext.owl> Class: pd:Cisco7603Configuration
SubClassOf: ((pd:containsCard some pd:Hot_Swappable_OSM) and (pd:containsCard some pd:Supervisor_engine_720)) or (pd:containsCard only (not (pd:Hot_Swappable_OSM)))
The extracted ontology together with extensions are the artefacts that constitute the input to the reasoner. The prototype allows for various types of reasoning, e.g. classi cation and consistency checking. We use classi cation to detect the exact type of a con guration individual, in order to support elaboration of partially incomplete models, which is the often case in physical devices management. Consistency checking was also successfully applied in order to detect and prevent errors in devices con gurations. In the remainder of this section we provide an example of classi cation and consistency check in the physical devices ontology. The examples di er in A-box axioms but use the same T-box. In Figure 10 the basic concepts of the ontologies are de ned: Configuration, Slot, Card classes. A Configuration may contain multiple Slots (via the hasSlot property), while a Slot may contain only one Card (via the hasSlot property). Additionally, the slots may be identi ed with an id property. Slot and Card classes are closed by enumerating all of their individuals.
Class: Configuration Class: Slot
EquivalentTo: {cisco1_slot_3, cisco1_slot_2, cisco1_slot_1} Class: Card
EquivalentTo: {supervisor_2_2, HS_OSM_1, supervisor_720_1, supervisor_720_3, H_OSM_2, supervisor_2_1, supervisor_2_3, spa_1} ObjectProperty: hasSlot
Domain: Configuration Range: Slot
Characteristics: InverseFunctional ObjectProperty: hasCard
Domain: Slot Range: Card
Characteristics: InverseFunctional , Functional DataProperty: id
Domain: Slot Characteristics: Functional 1. Cardinality restriction on hasSlot property - the con guration has exactly the number of slots speci ed in PDDSL. 2. Restriction on the required cards - the con guration has to contain cards speci ed in the slots marked as required in PDDSL. 3. Restriction on the optional cards - the con guration cannot contain other cards than those speci ed in PDDSL.
The mappings for the rst and third constraint are given in Figure 6. E.g. toSlotRequiredRestriction mapping generates restriction on the required cards. Class: Supervisors
SubClassOf: Card Class: Hot_Swappable_OSM
SubClassOf: Card
EquivalentTo: { HS_OSM_1 , H_OSM_2 } Class: SPA_interface_processors
SubClassOf: Card
EquivalentTo: { spa_1 } Class: Supervisor_engine_2
SubClassOf: Supervisors
EquivalentTo: {supervisor_2_1, supervisor_2_2, supervisor_2_3} Class: Supervisor_engine_720
SubClassOf: Supervisors EquivalentTo: {supervisor_720_1, supervisor_720_3}
Let us now consider the example of a con guration depicted in Figure 13. The model contains a con guration with three slots. Each of the slots contains a card. The model does not specify the speci c type of the con guration (cisco1 is an instance of the generic class Configuration). As a consequence, it is not clear what is the speci c type of the device.
In the generated ontology A-box, this model is represented by the set of individuals, speci ed in Figure 14. The A-box excerpts in this section omit the declarations of each card individuals for the sake of brevity, since all of them are listed in the EquivalentTo axioms of the respective classes in Figure 11.
Using the de nitions from the T-box the cisco1 individual can be classi ed as Cisco7603Configuration (see Figure 12 for the relevant constraints). Then, this inference could be used to provide guidance to the user of PDIDSL, i.e. suggest to change the type of cisco1 to Cisco7603Configuration.
Let us now consider an example where we use consistency checking to prevent illegal con gurations. Figure 15 depicts an example of Cisco7603Configuration. The con guration is invalid since the required Supervisors card is missing in slot 1.
The A-box axioms generated from this model are listed in Figure 16. Given the restrictions speci ed in Figure 12, the reasoner can detect the inconsistency (i.e the required card restriction does not hold). This fact then could be reported to the user by marking the inconsistent elements in the model and providing explanation of the reason of inconsistency. Moreover, employing more sophisticated reasoning services, the user could also get some guidance in form of suggestions what to change in the model in order to x it. 5
In [
Types: Configuration
Facts: hasSlot slot_1, hasSlot cslot_2, hasSlot slot_3 Individual: slot_1
Types: Slot
Facts: hasCard supervisor_2_1, id 1
Logic is a further prominent rule language that combines logical formulas with
object oriented and frame-based description features. Di erent works (e.g. [
[
[
Even though ontologies in computer science have been used for a long time, integration with domain speci c languages is a early innovation in the eld of data modelling. The problems described and appearing in everyday tasks are of an abstract nature and cannot easily be solved using existing tools and approaches. Introducing integrated models containing structure and semantic information will surely be a great advantage, and will lead to the improvement of existing systems, making them more user-friendly. The presented usage scenario serves as a proof of concept for ontology enriched prmodelling. Initial results have already proved its usefulness.
However, the prototype implementation presented in this paper does not fully take advantage of the integrated approach. The ontology is fully extracted by the means of model transformation, and only then it can be extended with additional constraints. This means that models and additional axioms have to be managed separately. In our future work in the MOST project, we will investigate how we can use the language integration approach to mitigate this shortcoming. The idea is to take pro t from both approaches described in Section 5, and to allow an integrated modelling of additional OWL axioms within PDDSL models.
This would not only solve the problem of e ective management of the models, but also improve the understanding of the relationship between the concepts from the two worlds. In general, it is assumed that large majority of models can be described using pure PDDSL constructs, while only limited number of uncommon cases require use of OWL extensions, thus OWL expertise would be required only for some of the users. When this extensions come into play in the integrated modelling could provide such users with understanding about the OWL meaning of PDDSL concepts without knowing the details of PDDSL2OWL transformations.