wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

65-6 Industrial Communication Systems
Even if the environment manager is still aware of who should not have access, ensuring that it happens
is another issue. Again, ontologies and, more specifically, the use of a base and several sub-ontologies,
provide a solution to this problem. By integrating an access concept (related to all types of information/
tasks/components in the project) in the base and sub-ontologies, it can be specified that certain groups
do not have access (read, write, none or all) to specific parts of the project.
The second issue relates to rapid reconfigurability (aim2) and this has two dimensions, namely,
(1) reconfigurability to bring about rapid production of a customized set of products demanded by the
customer for delivery in a compressed timeframe and (2) introduction of new processes and/or components
of a different level of granularity or made from new materials.
Previously, in order to address dimension one, a considerable amount of work has been done on flexible
manufacturing systems (FMS). However, these systems are inappropriate for the rapid production
of customized products because they have only a fixed number of processes that are in place and these
will probably be inadequate for the range of customization of products that might be required in product
construction. In addition, FMSs frequently absorb considerably more resources than are needed to
produce the specific product currently being produced. For these reasons, there has been a tendency in
recent research to move to other means of achieving reconfigurability. In this chapter, we explore the
two different approaches, namely, (1) use a combination of the ontologies and multi-agents [Hadzic 07]
and (2) use the semantic Web paradigm through a combination of ontologies and Web services [Wang 04],
[Dillon 07a,07b]. In approach (1), ontologies will be used as common knowledge base by agents working
at different sites. The agents themselves will be goal oriented and will collectively or individually seek
to achieve these, updating relevant instances of ontology classes when appropriate to allow monitoring
of the status of various processes through this. Our previous work on Software Engineering Ontology
[Wongthongtham 06] and Project Management Ontologies [Cheah 07] will help provide important
inputs on the way this can be achieved. The approach adopted for the design of Semantic Web services
will use further extensions of the RESTFUL and Web-based approaches and makes use of ontologies to
help in the identification of Web services that will be specified through the use of the triple computing
paradigm [Dillon 07a,07b]. Note this will not use the WSDL-based description but the use of a tuple
space to locate the required Web service. Previous studies [Pilioura 04], [Banaei-Kashani 04] suggested
that the existing Web services architecture based on remote procedure call (RPC) is not indeed “Web
oriented” because RPC is more suitable for a closed local network and raised concern that “Web services
do not have much in common with the Web” [Buschmann 96], and lead to potential weakness such as
scalability, performance, flexibility, and implementability [Piers 03].
Good manufacturing system architecture is crucial for multisite production. But how to define
“good” or “bad?” In the keynote paper [Dillon 07a,07b] at IFIP NPC 2007 Conference, we reviewed
four main architectural styles for SOA applications, namely, matchmaker, broker, peer-to-peer, Weboriented.
The Representational State Transfer (REST) [Fielding 02] uses a resource identifier (URI) to
provide an unambiguous and unique label for one particular Web resource. In the RESTful architectural
style, all resources are accessed with a generic interface resulting in a dramatic decrease in the
complexity of the semantics of the service interface during the service interaction W3C has recognized
this REST style as an alternative to WSDL. Triple Space Computing [Bussler 05] is built on top of several
technologies: Tuple Space [Gelernter 85], Publish/Subscribe paradigm [Eugster 03], Semantic Web,
and RDF [Vinoski 02]. [Klyne 04] Tuple Space employs the “persistently publish and read” paradigm
by leveraging the Tuple Space architecture and APIs. From an architecture perspective, Triple Space
Computing is, in effect, based on the natural confluence of Asynchronous Broker and RESTful styles.
The basic interactions between service provider and requester are rather straightforward: the service
provider can “write” one or more triples in a concrete identified Triple Space. The service requester
is able to “subscribe” triples that match with a template specified against its interests in a particular
concrete Triple Space. Whenever there is an update in the spaces, the Triple Space will “notify” related
service requesters indicating that there are triples available that match the template specified in its preceding
subscription, as shown in Figure 65.1.
© 2011 by Taylor and Francis Group, LLC