of the task: what is produced and how (i.e. what are the steps of the process).
Server needs to map task into skills and parametrise them appropriately. the approach to the previously considered cases and very similar ones only, thus Moreover, for each step, it should be clear how does it contribute to the goal. On the other side, available devices must be described in terms of operations they of an existing, correct, properly modelled production line. The system is not expected to propose novel solutions, nor to search for alternative ways of imTaking this into account, we have settled for a layered approach, with reconprecluding a more open-ended solution. are able to perform (skills) and conditions under which they can operate. Skill scenarios. The main issue with this approach is guaranteeing scalability and explementing the process. In particular, one should expect a detailed description It is rather obvious that the top-down AI approach is both computationally infeasible and impossible to model sucien tly well, while the bottom-up tendibility to new domains or to new kinds of devices. There is a risk of limiting In the bottom-up approach, the Skill Server is used only for reconguration of previously used parameter settings for a number of devices in a number of guration level at the bottom and (re)planning level on top of it. reparametrisation approach lacks generality and risks ending up as a database Nevertheless, in addition to the symbolic knowledge, there exist a number The overall structure of the Skill Server is shown in Figures 1 and 2. They (e.g. trajectory planner, device calibration and reparametrisation procedures, Skill Server considers such procedures as, essentially, black boxes. devices, tasks, workpieces and environment. Most of them can be specied on, at In eect, we have devoted most of our eorts to designing symbolic knowledge representation in a way that would be intuitive and useful in practice to our least, two levels of abstraction: simplied, generic descriptions (like a universal industrial partners (who, in general, have no background in AI) and, at the the project, however, we have been continuously investigating possibilities of etc.) which, in many contexts, should also be treated as knowledge. Despite Initially, we have identied several types of knowledge Skill Server will use: skills, depict, from two dieren t points of view, how the core Skill Server is integrated knowledge is simply too diverse to formalise in the timeframe we had. Therefore, introducing additional, intermediate levels of abstraction in between. pic kup skill) and instantiated ones (the operation of gripper picking the G1 way to put them into any kind of even semi-formal framework. This would be with various knowledge, reasoning and user interface modules and what kind of a very interesting research project in itself, but our experience shows that this information sources it has at its disposal. of domain-specic or device-specic procedures for calculating various aspects several attempts, however, we have not managed to nd an acceptable and useful windshield in factory , at time point and position Throughout W1 F tn pm). THE SKILL SERVER user interface for task definition actual task representation skill server main loop ontology devices skills instantiated skills operations virt
tasks virt workpiece ??? device library device#1234 ontology control pgm
CAD sim pgm HTTP access? distributed library plug−ins registration? interface? as a separate entities. was of paramount importance. There was little doubt that it should contain obvious was the status of tasks: whether they should be present in the ontology However, the former issue, i.e. what should the contents of the ontology be, knowledge about skills and about devices providing them. What was not so
Utility function interfaces
Path Time Vendor planning optimisation specific
Energy Grippability optimisation analysis s e c a f tr e n i n o i t a s i l a u s i v / n o i t a l u m i S
Open source
software
devices. For example, when talking about robots, it often appears useful to
specpounds, and that max image resolution makes sense only for cameras, and not
Therefore, it is probably unwise to exactly duplicate the hierarchy of skills with
The ontology contains knowledge about (abstract) skills and about devices.
out of it by treating it as little more than a gloried taxonomy. This part was
knowledge turned out to be and less with the ontology itself.
devices are almost eternal, in a sense that they can be input into the knowledge
However, on the most basic level, tasks necessarily have to correspond
dicient to specify that, for example, a concept of v acuum gripper is a subconcept
as well. Without their existence, no reasoning about them would be possible and
nican tly dieren t than the rest of information within the Ontology: skills and
considered sucien tly easy and sucien tly useful by all partners within a
conalgorithms. However, this has more to do with how unstructured this procedural
ify that a robot uses a gripper to perform some skill. It only seems natural to
possibility for the skill server to perform any kind of matching between them.
other hand, are dened within a very specic context and usually only useful
never managed to reach a satisfactory conclusion was the concept of compound
associate mass property with the concept of device and n umber of ngers
of knowledge, such as calibration procedure or specialised domain-dependent
Another issue we have been debating many times within the consortium but
sortium to make it universally accepted. In fact, in some regards the ontology
for robots. What we did not manage to do is to nd a way to express the purpose
of each skill and device, with natural inheritance rules. Thus we were able to
thus the Skill Server would not be able to perform some of its basic functions.
rectly, on the one-to-one basis, with the skills. Otherwise there would be no
express that robot-with-a-gripper can perform more (or rather dieren t) actions
This is an area for which ontology is well-suited, so it is both easy and
eA useful feature of the ontology was that it allowed us to specify properties
knowledge there, even the kinds for which it is clearly inappropriate.
within a particular factory shop and for a limited time.
with nger gripper, to specify that mass can be expressed in grams or
of gripper, which in turn is a subconcept of device. In a similar manner, a
base once and are useful for everybody any time in the future. Tasks, on the
v acuum-pickup skill is a subconcept of pic kup skill. Even though the
expressive power of an ontology goes much further, we did in fact get most mileage
resentational power of an ontology, at least in the form we had it in the project.
than robot alone. However, doing it properly turned out to be outside the
repproved too successful, and there has been signican t pressure to put virtually all
a corresponding hierarchy of tasks. Moreover, the lifetime of tasks is also
sigof those properties in a way that would be accessible to the non-symbolic parts
We have decided to center knowledge representation around the concepts of
devices (physical objects provided by their manufacturers) and skills (operations
3 Ontology Structure
The ontology contains three hierarchies: Devices, Skills and Properties. The
reason about. We have provided device manufacturers with a rudimentary
intera particular device reside and, depending on that, they are asked to ll in
valThere has been much debate about the need for complex (or composite) skills,
formed satisfactorily during the project, including the demonstration stage, but
as (arguably, quite complex) combinations of skills and parameters and therefore
It would make more sense to provide a more expressive way of building them,
there is no need to have them explicit in the vocabulary.
does a device oer) and the end users or systems integrators (who specify what
The static part of the knowledge is represented in an ontology: a data
strucis the best solution and would rather have a setup where dieren t abstraction
the nomenclature used and the relationships of dieren t concepts.
the end we have gone with the former approach, but we are not convinced this
when objects (skills or devices) are introduced in the structure. The main use
for ontology creation and manipulation, together with reasoners such as Racer[1],
device manufacturers can be mapped into the requirements of the users. It
perhierarchy is supposed to be a common ground where the capabilities oered by
in a distributed manner (for example, downloadable from device manufacturers’
levels could be used as appropriate.
web pages), we are actually storing all the devices in an SQL database.
of the ontology is to allow reasoning about skills matching particular tasks and
using a language like Finite State Machines or Sequential Function Charts. The
ture storing all the necessary relations between the terms used. While ontologies
it has by now became clear that we are missing a common understanding of an
tools we such as those are not appropriate for its intended end users. They worked
Fact++[
Finally, the Properties hierarchy forms a link between Devices and Skills. maximum weight limit). can be seen as a sequence of pic kup, mo ve and putdo wn skills. Second, it rationale for each operation and about motivations why a particular device and skills under certain conditions. A pure ontology may be used for retrieval, matchalong (at least) two axes: rst, they are time-ordered (or partially parallelised) Finally, we have implemented the core reasoning in Python programming concrete production process that will be the subject of reconguration. ThereIn addition, tasks constitute means of achieving a particular goal, and Skill ing into nd windshield, position windshield and x windshield subtasks. the ontology are the tasks. Tasks can be thought of as generalisations of skills makes sense to have hierarchy of tasks, with windshield tting task decomposing and simple classication, while other forms of reasoning, like planning, optiticular tasks (after some initial re/parametrisation) and devices oering those We have chosen Sequential Function Charts[5] to represent tasks, since it possibly ways to compare two solutions and determine when one of them is better which distinguish acceptable execution of this task from unacceptable ones, and ciations of skills, devices, workpieces, factory oor positions and time-line conthat are available in the ontology are those that skills refer to. language, gluing together the knowledge from ontology, SFCs and devicestraints. Where tasks are especially useful is on a higher level, when dening a than the other. fore the ontology does not need them, or putting it dieren tly, the only tasks dependent procedures provided in the form of plugins.
The major part of knowledge representation we have decided to store outside allows us to specify temporal ordering of operations in an intuitive and yet particular parameters were chosen. At the very least it requires a set of criteria exible way. We have used the open source tool JGrafchart for our prototype. sequences of skills (or rather of skill applications): for example, a relocate task Server needs to have a representation of that goal, in particular to reason about The bottom level of tasks hierarchy are operations, which are a kind of assoIn our approach the ontology is used for reasoning about skills matching parmisations, consistency checks, etc., need to be done by reasoners, either general4 Knowledge Representation outside Ontology system. edness, letting some parts be completed and stored at the device manufacturer’s by the system providers, while on the other hand it may benet from distributtational complexity, and to their specicit y to particular devices, they cannot asked, thus achieving exibilit y and adaptability of the reasoning part of the power and eciency , being able to handle either a restricted Description Logic priate data structures, so that on one hand the ontology can be easily extended purpose ones, or specialised for the task. The generic tools that have been used We have also developed tools for storing and retrieving knowledge in approfull OWL [8] representation, but using exponential search algorithms. The user of optimisation tasks that may be requested by the user. Due to their compureasoning blocks tting the structure of the server. has the possibility of choosing a dieren t reasoner depending on the question be implemented in a general-purpose manner but rather require their specic site. Yet another set of requirements is put on the reasoning process by the list by in the project (Racer, Fact++, Algernon and Pellet) dier in their reasoning language [6] (like OWL-DL oered by ProtØgØ) in an ecien t manner [7], or a 5 Related Work tensive research aimed at supporting the engineering activities in production at the W3Consortium’s Semantic Web site [10]. In particular, the specications ysis, reported for example in [12], there is in principle no documented research design by providing modelling languages and tools allowing formal, automatic The work that originated discussions over semantic web and, in particular, on http://www.sensorml.org for an extensive documentation). A dual enterprise, voted solely to this domain. One of the recent ones, and a very good overview guage, (URML), from the University of Karlsruhe, as URML does not provide itly stating goal of being general-purpose tools. We may name here the Sensor with available tools for using those formalisms, can be found there. not exactly tting our point of view either, is the unie d robot modelling lantools are heavily domain-dependent, with a small number of exceptions explicModelling Language, or Sensor ML for short, oering a rich sensor ontology (see representation facilities for the dynamic aspects of robot performance. of the eld, is by Brachman and Levesque [9].
The research on knowledge representation has been extensively documented, analysis of the discussed process. Quite naturally, most of those formalisms and on using ontologies in automated production planning. However, there is an exboth in general textbooks on articial intelligence and in numerous books deproduction processes has been done at NIST which created the Process SpeciFinally, an important attempt to formalise the language for speaking about Production planning is usually considered in AI to be a part of the autoof the most popular KR formalisms, like OWL [8] or DAML-OIL [11], together matic planning domain. However, besides the classical manufacturability analontologies, has an extensive library of published documents available for example cation Language [13]. The language, and some of the associated tools, are serving as a reference point for the ontology developed within SIARAS. cumbersome tool, and also those where it proved to be very helpful. We wish we will allow them to avoid some of the pitfalls we have encountered.
The main point of our discussion was the use of Ontology and what are the way. We have discussed situations where ontology turned out to be a rather helpful to other people designing knowledge bases for industry applications and benets and costs associated with representing knowledge in such structured of the representation we have ended up with, but unfortunately we do not have were able to oer some kind of evaluation of the approach we have chosen and anything more concrete than our own reections.
In this paper we discuss the knowledge representation we use in the EU-funded project SIARAS, and present the most interesting points where real-life considerations clashed with our initial assumptions. We hope this overview will be shop, DL’99. (1999) WSEAS International Conference on Computers. (2008) 274279 report, National Institute of Standards and Technology (NIST) (2000) gan Kaufmann (2004) Morgan Kaufmann (2004) 7. Buchheit, M., Donini, F.M., Schaerf, A.: Decidable reasoning in terminological (2002) specication language (PSL): Overview and version 1.0 specication. Technical 8. W3C: Semantic web (2003) eds.: The Description Logic Handbook. Cambridge University Press (2003) (1993) 109138 13. Schleno, C., Gruninger, M., Tissot, F., Valois, J., Lubell, J., Lee, J.: The process petri nets to build robust mobile robot applications: Robograph. In: International 1. Haarslev, V., Mller, R.: Racer: A core inference engine for the semantic web P.F.: Oil: An ontology infrastructure for the semantic web. IEEE Intelligent Conference on Robotics and Automation. (2008) 13721377 104 of CEUR Workshop Proceedings. (2004) 11. Fensel, D., Horrocks, I., van Harmelen, F., McGuinness, D.L., Patel-Schneider, 3. Stoica, F., Pah, I.: Intelligent agents in ontology-based applications. In: 12th 4. Sirin, E., Parsia, B.: Pellet: An OWL DL reasoner. In: Description Logics. Volume 6. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F., Systems 16(2) (2001) 12. Ghallab, M., Nau, D., Traverso, P.: Automated Planning, Theory and Practice. 5. FernÆndez, J.L., Sanz, R., Domonte, E.P., Alonso, C.: Using hierarchical binary 9. Brachman, R.J., Levesque, H.J.: Knowledge Representation and Reasoning. Mor2. Horrocks, I.: FaCT and iFaCT. In: Proceedings of the Description Logics Workknowledge representation systems. Journal of Articial Intelligence Research 1(1) 10. W3C: Semantic web (2001)