Warning:
This wiki has been archived and is now read-only.

RequirementsAndUseCases-Draft

From Object Memory Modeling Incubator Group Wiki
Jump to: navigation, search

This page serves as a collector for requirements and use cases concerning the object memory model, which still need further discussion.

Production

Task Knowledge (TU Darmstadt)

Initial author: Daniel Schreiber

In complex production environments item level information is often necessary to carry out tasks. For example the desired torque and angle of fastening screws of an aircraft part. Once the part is fastened, the actual values need to be recorded.

Currently such information is maintained in a separate digital model of the aircraft, which is often outdated. Directly maintaining this information on a DPM which is read and/or written by smart tools would ensure the model remains acurate.

Discussion

  • Torque and angle values are most likely custom information which should not be part of OMM.
  • How do the smart tools identify whether the necessary information is present in the DPM? Working with non-DPM enabled objects should still be possible.

Example

SmartProducts has not yet defined an XML representation. The information is currently stored as RDF triples. These could be serialized into XML, but this would be highly inefficient

Decentralized Production Process Control (DFKI-IFS)

Initial author: Marc Seißler


The use of decentralized on-product DOM information to parameterize production facilities is a promising way allowing for more efficient and more flexible factory processes. By storing all production-related information directly on the item to be produced, a production system becomes independent from backend systems and that way far more resistant against disturbances and interruptions in comparison to traditional centralized systems. In the future, products knowing about their production will also enable a whole set of new dispatching strategies allowing for a more flexible processing of incoming orders than it is the case today. As the use of on-product information will facilitate parameterization of processes on a very low communication level directly between sensor, PLC and actors, production processes will become more and more independent from supervisory control systems and thus, far more robust towards communication breakdowns. To enable a decentralized production, following information have to be stored on a OMM:

  • A description of the production process steps
  • Physical object characteristics:
    • height, weight, orientation, …
  • Quality characteristics:
    • timestamps, production status, quality status

Discussion

  • The XML Format for the specification of product height and weight is sub optimal (<height>7cm</height>) I would like to suggest to change the XML specification to: <height unit="cm">7</height>

Example

   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <spm:semprom version="1.0" xmlns:spm="http://semprom.de/semprom#">
   <metas>
       <blockMeta>
           <blockID>_BLOCK_0_</blockID>
           <blockType>OMM_CUSTOM</blockType>
           <contentType>application/xml</contentType>
           <created>
              <timestamp>2011-01-30T18:30:00+02:00</timestamp>
              <creator type="duns">19-550-5177</creator>
           </created>
          <modified>
              <timestamp>2011-01-30T18:35:00+02:00</timestamp>
              <modifier type="email">user@w3c.org</modifier>
          </modified>
          <blockContentDescription>
              <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Retail" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Pharmacy" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
          </blockContentDescription>
       </blockMeta>
       <blockMeta>
           <blockID>_BLOCK_1_</blockID>
           <blockType>OMM_CUSTOM</blockType>
           <contentType>application/xml</contentType>
           <created>
              <timestamp>2011-01-30T18:30:00+02:00</timestamp>
              <creator type="duns">19-550-5177</creator>
           </created>
          <modified>
              <timestamp>2011-01-30T18:35:00+02:00</timestamp>
              <modifier type="email">user@w3c.org</modifier>
          </modified>
          <blockContentDescription>
              <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Retail" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Pharmacy" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
          </blockContentDescription>
       </blockMeta>
       <blockMeta>
           <blockID>_BLOCK_2_</blockID>
           <blockType>OMM_CUSTOM</blockType>
           <contentType>application/xml</contentType>
           <created>
              <timestamp>2011-01-30T18:30:00+02:00</timestamp>
              <creator type="duns">19-550-5177</creator>
           </created>
          <modified>
              <timestamp>2011-01-30T18:35:00+02:00</timestamp>
              <modifier type="email">user@w3c.org</modifier>
          </modified>
          <blockContentDescription>
              <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Production" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Manufacturing" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#Expert" />
              <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
          </blockContentDescription>
       </blockMeta>
   </metas>
   <blocks>
       <coreBlockData blockID="_BLOCK_0_">
           <version>1.0</version>
           <product_name>Smart Drug Case</product_name>
           <company_name>SmartFactory</company_name>
           <height>7cm</height>
           <weight>10g</weight>
       </coreBlockData>
       <attributesBlockData blockID="_BLOCK_1_">
           <namespace>semprom.SF.products.smartDrugCase.process</namespace>
           <attribute key="numberPillA">1</attribute>
           <attribute key="numberPillB">0</attribute>
           <attribute key="numberPillC">1</attribute>
           <attribute key="basinType">1</attribute>
       </attributesBlockData>
       <attributesBlockData blockID="_BLOCK_2_">
           <namespace>semprom.SF.products.smartDrugCase.quality</namespace>
           <attribute key="productionStart">2011-01-20T12:32:14+01:00</attribute>
           <attribute key="qualitySignPillA">1</attribute>
           <attribute key="qualitySignPillB">1</attribute>
           <attribute key="qualitySignPillC">1</attribute>
           <attribute key="qualitySignWeight">1</attribute>
           <attribute key="qualitySignCap">1</attribute>
           <attribute key="wasteBit">1</attribute>
       </attributesBlockData>
   </blocks>
   </spm:semprom>

Robust Production Process (SAP)

Initial author: Barbara Schennerlein

Complex production processes are error-prone. For more efficiency of production process, to avoid errors and to increase product quality the real life process data will be record on a DPM linked with objects. These objects can be products as well as the machines and tools which are needed for production. The objects linked with DPM interact and communicate each other. So a product is able to communicate about a failure during a routing process, in consequence the next routing process cannot start. Besides of that such specific process information might be interesting for other companies or end users. The following production specific information might be stored in a DPM:

  • Time stamps regarding specific production events
    • Routing start / routing finish
    • Production start / production finish
  • Process history information
    • Routing successful finished
    • Routing finished with errors
    • Quality check successful
    • Unexpected events
  • Process environment information
    • Used tools
    • Involved employees and their skills
    • Energy consumption

Discussion

  • Is there information which can be standardized for specific domains (in this case domain “production”) or are they in every case custom specific? How do we define the delimitation between OMM and custom specific data?
  • How is possible to define the priority of various information clusters for one domain / cross domain

Example

The following example represents different categories of production information. The XML structure is based on the SemProM format. In this case, production information as a log of events is modeled as part of attribute block.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<spm:semprom version="1.0" xmlns:spm="http://semprom.de/semprom#">

      <metas>

            <blockMeta blockID="0">

                  <blockType>Core</blockType>

                  <contentType>106</contentType>

                  <creationTimestamp>1292931142</creationTimestamp>

                  <creatorType>DUNS</creatorType>

                  <creator>Etngbw==</creator>

                  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>

                  <lastModifierType>DUNS</lastModifierType>

                  <lastModifier>Etngbw==</lastModifier>

                  <signatureType>None</signatureType>

            </blockMeta>

            <blockMeta blockID="1">

                  <blockType>Ids</blockType>

                  <contentType>106</contentType>

                  <creationTimestamp>1292931142</creationTimestamp>

                  <creatorType>DUNS</creatorType>

                  <creator>Etngbw==</creator>

                  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>

                  <lastModifierType>DUNS</lastModifierType>

                  <lastModifier>Etngbw==</lastModifier>

                  <signatureType>None</signatureType>

            </blockMeta>

            <blockMeta blockID="2">

                  <blockType>Attributes</blockType>

                  <contentType>106</contentType>

                  <creationTimestamp>1292931142</creationTimestamp>

                  <creatorType>DUNS</creatorType>

                  <creator>Etngbw==</creator>

                  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>

                  <lastModifierType>DUNS</lastModifierType>

                  <lastModifier>Etngbw==</lastModifier>

                  <signatureType>None</signatureType>

            </blockMeta>

      </metas>

      <blocks>

            <coreBlockData blockID="0">

                  <version>1.0</version>

<product_name>SIMATIC PXS120 SONAR SENSOR K0</product_name>

                  <product_type>Näherungsschalter</product_type>

                  <company_name>Siemens</company_name>

                  <part_number>3RG6343-3AB00</part_number>

            </coreBlockData>

            <idsBlockData blockID="1">

                  <primaryID idType="rfid">4AgBziEDWUQ=</primaryID>

                  <id idType="uri">http://10.55.9.39:8080/semprom_server/report?Id=5341503A486F6C7A626C6F636B2E706466202020

                  </id>

            </idsBlockData>

            <attributesBlockData blockID="2">

                  <namespace>semprom.product.log</namespace>

<attribute key="2010-12-21T12:32:14+01:00">
Transport started</attribute>

<attribute key="2010-12-21T12:20:14+01:00">
Production started</attribute>

<attribute key="2010-12-21T12:30:14+01:00">
Production finished</attribute>

<attribute key="2010-12-21T12:33:14+01:00">
Transport finished</attribute>

<attribute key="2010-12-21T12:31:44+01:00">
Quality inspection successfully passed</attribute>

            </attributesBlockData>

      </blocks>

</spm:semprom>

 

Localization of Objects (SAP)

Initial author: Barbara Schennerlein

In industrial environment and complex automated production processes are used many machines and moveable tools. In order to efficient resource use the necessary tools are shared, so in case of unexpected events there is the necessity for quick finding alternative tools. Otherwise the use of moveable tools requires effective localization functionality. For localization and history of object use the following information might be stored on a DPM:

  • Object-Type: person, object …
  • Localization: used by, located in, coordinates (for moveable objects)
  • Time stamp: start / finish for every used event
  • Status

Discussion

  • Is the history object localization log a custom specific information or part of OMM? How do we define the delimitation between OMM and custom specific data?
  • Is XML the right representation language? Are there other methods, particularly in context of semantics (in this case: object is used by; object is located in… OWL, RDF)

Example

The following example represents a history list of object (tool) movements. The XML structure is based on the SemProM format. In this case, localization information is modeled as additional attribute block elements (block 2+3).

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<spm:semprom version="1.0" xmlns:spm="http://semprom.de/semprom#">

      <metas>

            <blockMeta blockID="0">

                  …

            </blockMeta>

            <blockMeta blockID="1">

                  …

            </blockMeta>

            <blockMeta blockID="2">

                  …

            </blockMeta>

<blockMeta blockID="3">

                  …

            </blockMeta>

      </metas>

      <blocks>

            <coreBlockData blockID="0">

                  <version>1.0</version>

                  <product_name>PALLET TRANSPORTER NE3.6</product_name>

                  <product_type>Pallet Transporter</product_type>

                  <company_name>Caterpillar Germany</company_name>

                  <part_number>3RN365-3CD00</part_number>

                  <height>2.10m</height>

                  <weight>730kg</weight>

            </coreBlockData>

            <idsBlockData blockID="1">

                  <primaryID idType="rfid">5AgBziEEEUQ=</primaryID>

            </idsBlockData>

            <attributesBlockData blockID="2">

                  <namespace>semprom.tool.log</namespace>

<attribute key="2011-11-21T12:31:11+01:00">
Location initialized</attribute>

<attribute key="2011-12-12T11:21:11+01:00">
Location changed</attribute>

<attribute key="2011-01-11T10:31:11+01:00">
Location changed</attribute>                        

            </attributesBlockData>

            <attributesBlockData blockID="3">

                  <namespace>semprom.tool.location</namespace>

                  <attribute key="coordinate_type">layout3.2</attribute>

                  <attribute key="coordinates_x">1250</attribute>

                  <attribute key="coordinates_y">477</attribute>

            </attributesBlockData>

      </blocks>

</spm:semprom>

 

Assembling objects with DPMs (Siemens)

A typical production process is the assembling of component parts to create a higher-value object. In the case of high-class objects such as automobiles, turbines, or computer tomographs it is reasonable to assume that even the components are valuable enough to have its own DPM. Examples could be the gearbox of an automobile or the low pressure section of a turbine.

  • Clearly, no information must be lost during the assembling of the parts.
  • The information of all DPMs must stay accessible and changeable. (E.g. the gearbox's DPM could include its actual milage)
  • The whole object is more than a collection of parts. I.e. the assembled object (e.g. the automobile) has its own DPM with lifecycle information itself as a whole (e.g. warranty information).
  • It must be possible to access information specifically about the whole object or one or more of its parts.
  • For a reasonable handling it should be possible to build up a data structure which reflects the objects assembly. This structure should be browsable.
  • If parts of high-value products fail, these parts are repaired or exchanged (as opposed to low-value products that are just thrown away). It must therefore be possible to alter the structure that reflects the objects assembly. Parts may be added or removed, connections between parts may be altered.
  • If a part leaves the object (is dismantled) the object's DPM should reflect its complete lifecycle including its life as a part of the object. I.e. a part should remember where it has been. As a counterpart the whole object should also be able to log the information about its dismantled parts. (E.g. the automobile knows that 2 engines have already been replaced. An engine should know that it has been built into 2 cars.)


Discussion

Example

Logistics

Monitoring integrity (DFKI-IB)

Initial author: Jens Haupert, Alexander Kröner

Supply Chain integrity is monitored taking container transport as an example being able to inform and react in case of integrity violation. The validation of integrity might be of special relevance not only for the logistics expert, but for all of his business partners up to the consumer. For instance, a container might be linked with an object memory carrying the following data:

  • List of parameters to be monitored (e.g., temperature, humidity)
  • Violation criteria (e.g., temperature value). Note: Violation criteria might be complex functions (e.g., exceeding a humidity boundary value over a certain timespan)
  • List of recorded violations within their spatial and temporal context

Discussion

  • This case indicates some need for a standardized structure of event lists. To be discussed: Is this still part of the object memory model, or part of the content model (e.g., a standardized model for CEP)?
  • For memories with a large number of information chunks, independent from the actual content a standardized information block carrying hints to "crucial" changes in the memory (e.g., an integrity violation recently observed) might be of interest to indicate (a) the need for reading the memory and (b) to provide a hint to the respective part.

Example

The following example represents a list of integrity violations such as "Delay" or "Temperature". The XML structure is based on the SemProM format. In this case, integrity violations are modeled as an event list stored in a customBlockData element. Events and list are not part of the SemProM format. Violations are only represented as flags with timestamp and duration; their detection and computation is performed by the application.

<block>
  <blockMeta>
    <blockID>_BLOCK_001_</blockID>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-03-29T09:30:00+02:00</timestamp>
      <creator type="email">jens.haupert@dfki.de</creator>
    </created>
    <blockContentDescription>
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#TransportationEvent" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Logistics" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Transport" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="warranty">
        <tag type="text" value="shelf_life" />
      </tag>
      <tag type="text" value="temperature" />
      <tag type="text" value="event" />
    </blockContentDescription>
  </blockMeta>
  <blockData>
    <customBlockData blockID="_BLOCK_001_">
	  (...) <!-- see example above -->
	</customBlockData>
  </blockData>
</block>

Complex Transport (DFKI-IB)

Initial author: Jens Haupert, Alexander Kröner

The transport of some item may require a sequencing of services provided by several logistics providers. Each one of these should be able to document the service execution on the object memory of transported goods. This requires:

  • Several (independent) transport specifications, individually entered by the different logistics providers.

Discussion

  • Details of a transport specification might require a complex content model (of scope). However, selected attributes of a transport might be valuable for selecting content from an object memory.

Example

The following example describes a logistics process involving three logistic actors in a pharmacy scenario. The encoding reflects two aspects of the SemProM format. First of all, content is organized using "blocks". Each block has a separate header ("blockMeta"). In the matching binary encoding, all headers are stored before the first content block; rationale for this organization is to facilitate search for the presence of some content block. The headers provide very basic information concerning the matching content block - in this case, timestamps, the respective product lifecycle step, and the vertical market. The content blocks may carry an arbitrary payload.

<block>
  <blockMeta>
    <blockID>_BLOCK_101_</blockID>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-03-29T09:30:00+02:00</timestamp>
      <creator type="email">sampleUser@logisticsOne.org</creator>
    </created>
    <blockContentDescription>
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#TransportationEvent" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Logistics" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Pharmacy" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="warranty">
        <tag type="text" value="shelf_life" />
      </tag>
      <tag type="text" value="temperature" />
      <tag type="text" value="event" />
    </blockContentDescription>
  </blockMeta>
  <blockData>
    <customBlockData blockID="_BLOCK_101_" >(...)</customBlockData>
  </blockData>
</block>
<block>
  <blockMeta>
    <blockID>_BLOCK_102_</blockID>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-03-29T09:40:00+02:00</timestamp>
      <creator type="email">sampleUser@logisticsTwo.org</creator>
    </created>
    <blockContentDescription>
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#TransportationEvent" />
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#TransportIrregularity" />
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#HighTemperature" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Logistics" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Transport" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="warranty">
        <tag type="text" value="irregularity">
	  <tag type="text" value="solved" />
	</tag>
      </tag>	   
      <tag type="text" value="measures">
        <tag type="text" value="counteractive" />
      </tag>
      <tag type="text" value="temperature">
        <tag type="text" value="high" />
      </tag>
      <tag type="text" value="event" />
    </blockContentDescription>
  </blockMeta>
  <blockData>
    <customBlockData blockID="_BLOCK_102_" >(...)</customBlockData>
  </blockData>
</block>
<block>
  <blockMeta>
    <blockID>_BLOCK_103_</blockID>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/xml</contentType>
    <created>
      <timestamp>2011-03-29T09:50:00+02:00</timestamp>
      <creator type="email">sampleUser@logisticsThree.org</creator>
    </created>
    <blockContentDescription>
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#TransportationEvent" />
      <tag type="ontology" value="http://www.dfki.de/ont/omm.owl#EmptyEvent" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/phase.owl#Logistics" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/verticalMarket.owl#Transport" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/userRole.owl#GeneralUser" />
      <tag type="ontology" value="http://omm.org/ontologies/v1/importance.owl#Medium" />
      <tag type="text" value="temperature">
        <tag type="text" value="no_data" />
      </tag>
      <tag type="text" value="event" />
    </blockContentDescription>
  </blockMeta>
  <blockData>
    <customBlockData blockID="_BLOCK_103_" >(...)</customBlockData>
  </blockData>
</block>

Retail

Product Recommendation (SAP)

Initial author: Barbara Schennerlein

Consumers of particularly expensive products frequently ask other consumers for their product experiences. Buying decisions often depend from such evaluations. On one hand consumers should get the possibility to evaluate products and store such evaluation on the DPM, on the other hand it should be possible to access to DPM with a mobile device for getting evaluation relevant information. For object evaluation the following information might be stored on a DPM:

  • Evaluation criteria group: depends on product group / product classification (e.g. consumer electronic devices, food )
  • Evaluation criteria: Ease of Use; Prize; Design; Lifespan; Interfaces, Functionality…

Discussion

  • Is the evaluation information, which is very often used in many domains part of OMM? How do we define the delimitation between OMM and custom specific data?
  • Are there product class specific evaluation criteria groups? (e.g. evaluation criteria for food differ from evaluation criteria for electronic devices)

Example

The following example represents a list of evaluation criteria and their specific values for a consumer electronic device (e.g. hard disc video recorder). The XML structure is based on the SemProM format. In this case, evaluation information is modeled as a attributes block data element.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<spm:semprom version="1.0" xmlns:spm="http://semprom.de/semprom#">

      <metas>

            <blockMeta blockID="0">

                  …

            </blockMeta>

            <blockMeta blockID="1">

                  …

            </blockMeta>

            <blockMeta blockID="2">

                  …

            </blockMeta>

      </metas>

      <blocks>

            <coreBlockData blockID="0">

                  <version>1.0</version>

                  <product_name>HD RECORDER HDR1200</product_name>

                  <product_type>Harddisc Video Recorder</product_type>

                  <company_name>Panasonic</company_name>

                  <part_number>SL03234-13</part_number>               

            </coreBlockData>

            <idsBlockData blockID="1">

                  <primaryID idType="sgtin96">MADg3NjU0IAAAAAA</primaryID>

            </idsBlockData>

            <attributesBlockData blockID="2">

                  <namespace>semprom.product.rate.electronics</namespace>

                  <attribute key="ease_of_use">+2.3</attribute>

                  <attribute key="price">-0.4</attribute>

                  <attribute key="design">+1</attribute>        

                  <attribute key="ratings">12</attribute

                  <attribute key="recommendation">

many features, excellent picture quality</attribute>

            </attributesBlockData>            

</blocks>

</spm:semprom>

 



Provenance Information (UCL)

Initial Author: Ralph Barthel

In retail scenarios it is often perceived as desirable to have provenance information about the origin of an object or previous interactions with an object that may impact consumer behavior. Examples of this are added information about the producer of a product such as in a fair trade shop, previous owners of the object in scenarios that deal with second hand goods and more generally peoples interactions with a product over the course of its lifecycle. This provenance information can include different media and can be open ended in its structure. Examples include stories of people about objects e.g. why they donate/sell an object, how the labeled object was created and under which conditions, a personal memory relating to childhood or certain time in life that is linked to a particular object etc. These memories can consist of text or/and of other media such as video and audio.

Discussion

  • List of memories associated with an object
  • Source of this information might be different providers-each proving single or multiple pieces of object memory information
  • Support for different content models since this work group is not aiming to define the contents of object memories
  • Since lifecycle data of provenances is captured the format needs to be compact as information might be added continually
  • Interoperability with linked data best practises to leverage synergies with semantic web practises

Example

The following example represents user-generated data created as a result of interactions with an object during its lifecycle.

    <block>
        <blockMeta>
           <blockType>OMM_CUSTOM</blockType>
           <blockID>9ahe+wSe8Po</blockID>
           <created>
               <timestamp>2011-04-04T07:07:00+01:00</timestamp>
           	<creator type="email">xyz@somedomain.com</creator>
           </created>
           <contentType>application/json</contentType>
           <blockContentDescription>
           	<tag type="text" value="description" />
     		    <tag type="text" value="keywords" />
     		    <tag type="text" value="name" />
     		    <tag type="text" value="photo" />
     		    <tag type="text" value="dateOfOwnership" />
     		    <tag type="text" value="yearOfProduction" />
     	            <tag type="text" value="tales" />
           </blockContentDescription>
      </blockMeta>
      <blockMeta>
          <blockType>OMM_CUSTOM</blockType>
          <blockID>tale_1</blockID>
          <created>
           	<timestamp>2011-04-06T10:41:05+01:00</timestamp>
           	<creator type="email">xyz@somedomain.com</creator>
           </created>
           <contentType>application/json</contentType>
           <blockContentDescription>
               <tag type="text" value="author" />
               <tag type="text" value="title" />
               <tag type="text" value="story" />
               <tag type="text" value="keywords"/>
               <tag type="text" value="location">
                   <tag type="text" value="latitude"/>
                   <tag type="text" value="longitude"/>
                   <tag type="text" value="woeid"/>
               </tag>
               <tag type="text" value="dateTimeCreated" />
               <tag type="text" value="mediaReferences" />
          </blockContentDescription>
      </blockMeta>
      <blockMeta>
          <blockType>OMM_CUSTOM</blockType>
          <blockID>media_1</blockID>
          <created>
              <timestamp>2011-04-06T10:41:33+01:00</timestamp>
              <creator type="email">xyz@somedomain.com</creator>
          </created>
          <contentType>application/json</contentType>
          <blockDescription>
              <tag type="text" value="mediaType"/>
              <tag type="text" value="uri" />
              <tag type="text" value="dateTimeCreated" />
          </blockDescription>
      </blockMeta>
      <blockMeta>
          <blockType>OMM_CUSTOM</blockType>
          <blockID>comment_1</blockID>
          <created>
              <timestamp>2011-04-06T10:42:15+01:00</timestamp>
              <creator type="email">xyz@somedomain.com</creator>
          </created>
          <contentType>application/json</contentType>
          <blockDescription>
              <tag type="text" value="comment" />
              <tag type="text" value="commenter" /> 
     	   </blockDescription>
      </blockMeta>
      <blockData>...</blockData>
   </block>

Metadata

We provide metadata as RDFa and in Open Graph Protocol format embedded in HTML views. The Open Graph protocol metadata is rendered in the <head> section of the HTML view. The relevant namespaces are defined in the <html> element.

    <meta property="og:title" content="cartonnage mummy mask of a man of a man" />
    <meta property="og:type" content="thing" />
    <meta property="og:url" content="http://talesofthings.com/totem/totem_view/5840/" />
    <meta property="og:description" content="Period: Dynasty 11 UC31377 Place: Sedment (Egypt R - Z / Egypt) Cartonnage mummy mask of man with 
      light ochre face, eyebrows, eyes and lids are black, .... moustache and beard blue, wig black. Wears broad collar; colours probably green, 
      red, ochre, white and black. Cartonnage has almost two layers of linen.Created to cover the mummy in the inner coffin, the helmet-like mask 
      was placed over the head and chest, and bore the likeness of the deceased. Such were principally used to protect the mummy's face but 
      could also act as substitutes for the mummified head should it be damaged or lost. Egyptians believed that the spirit or ba survived death 
      and could leave the confines of a tomb. The mummy mask therefore provided the means for the returning ba to recognize its host, whose face 
      was hidden by layers of bandage." />
    <meta property="og:image" content="http://talesofthings.com/totem_media/things/UC31377.JPG" />
    <meta property="og:site_name" content="Tales of Things" />
    <meta property="og:latitude" content="51.495065" />
    <meta property="og:longitude" content="-0.131836" />

The RDFa (Resource Description Framework – in – attributes) data is embedded in the HTML content for example as follows.

    <span property="dc:subject" > Petrie Museum, Ancient Egypt, Dynasty 11, Dynasty XI, mummy, mask</span>
    <p property="dc:description">Period: Dynasty 11</p>
    <ul>
        ...
        <li property="dc:created">Created: Tue 15 Feb 2011</li>
        ...
    </ul>

Consumer

Procedural Knowledge (TU Darmstadt)

Intial author: Daniel Schreiber

Products sometimes require complicated or rarely used routines for maintenance. For example, the descaling routine of a coffee machine is often not remembered when it needs to be performed. Currently, such information has to be looked up in a manual, where step-by-step instructions are given,

Discussion

  • Can such knowledge be represented as part of the DPM, or should it just contain a link to the online manual?
  • Should at least a list of procedures be stored as part of the DPM?

Example

The descaling procedure for the coffee machine might be stored as a workflow in the DPM, e.g., using XPDL. (The example is not the descaling procedure, but a less complicated, shorter workflow)


<block>
  <blockMeta>
    <blockID>_BLOCK_101_</blockID>
    <blockType>OMM_CUSTOM</blockType>
    <contentType>application/x-xpdl</contentType>
    <created>
      <timestamp>2010-12-01T09:30:00+02:00</timestamp>
      <creator type="email">schreiber@manufact.org</creator>
    </created>
    <blockContentDescription>
	<tag type="ontology" value="http://domain.org/other_ontology/def.owl#MaintenanceProcedure" />
    </blockContentDescription>
  </blockMeta>
  <blockData>
    <customBlockData blockID="_BLOCK_101_" >(... complete xpdl document ...)</customBlockData>
  </blockData>
</block>

Maintenance

RFID-based Maintenance (Siemens)

Maintenance includes all measures during the lifetime of a unit to assure the requested functioning of that unit. However, maintenance itself is the largest cost-factor during the operations phase of a plant. Any measure which leads to a more efficient maintenance process will therefore have a large impact on the performance (revenue) of a plant.

RFID-based maintenance greatly enhances the efficiency of the maintenance process by

  • allowing for fast identification of assets
  • providing relevant asset information at hand (electronic boiler plate)
  • providing information about maintenance activities (e.g. maintenance log)
  • ensuring that maintenance personel have to be at the place, i.e. it is more difficult to fake maintenance jobs
  • allowing for new features like electronic locking or clearing of areas/assets

The asset has to be easily identifiable via the DPM. Thereby, the system must support multiple IDs per asset, because typically an asset has at least a serial number, a plant identification code (PIC), an equipment identification code (EIC), and a location identification code (LOC).

The following maintenance specific information might be stored in a DPM:

  • Maintenance Log
    • Maintenance job n (the latest)
      • Timestamp (end of job)
      • Unique job ID
      • Personel ID of maintenance worker
      • Job category (inspection, cleaning, ...)
      • Further description
    • Maintenance job n-1
    • ...
  • Locking
    • Personel ID of maintenance worker A that has locked the asset
    • Personel ID of maintenance worker B that has locked the asset
    • ...
  • Maintenance Information
    • Textfields with maintenance relevant information (e.g. "Has the tendency to leak oil", "Has made rattling noises during last inspection")

Discussion

Example

Das ecl@ss-Beispiel beschreibt keine Maintenance-Daten, zeigt aber das Integrieren einer Beschreibung anhand eines anderen Standards.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<spm:semprom version="1.0" xmlns:spm="http://semprom.de/semprom#">
<metas>
<blockMeta blockID="0">
 <blockType>Core</blockType>
 <contentType>106</contentType>
 <creationTimestamp>1292931142</creationTimestamp>
 <creatorType>e-mail</creatorType>
 <creator>joerg.neidig@siemens.com</creator>
 <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>
 <lastModifierType>e-mail</lastModifierType>
 <lastModifier>joerg.neidig@siemens.com</lastModifier>
 <signatureType>None</signatureType>
</blockMeta>
<blockMeta blockID="1">
 <blockType>Ids</blockType>
 <contentType>106</contentType>
 <creationTimestamp>1292931142</creationTimestamp>
 <creatorType>e-mail</creatorType>
 <creator>joerg.neidig@siemens.com</creator>
 <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>
 <lastModifierType>e-mail</lastModifierType>
 <lastModifier>joerg.neidig@siemens.com</lastModifier>
 <signatureType>None</signatureType>
</blockMeta>
<blockMeta blockID="2">
  <blockType>Custom</blockType>
  <contentType>106</contentType>
  <creationTimestamp>1292931142</creationTimestamp>
  <creatorType>e-mail</creatorType>
  <creator>joerg.neidig@siemens.com</creator>
  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>
  <lastModifierType>e-mail</lastModifierType>
  <lastModifier>joerg.neidig@siemens.com</lastModifier>
  <signatureType>None</signatureType>
</blockMeta>
<blockMeta blockID="3">
  <blockType>Custom</blockType>
  <contentType>106</contentType>
  <creationTimestamp>1292931142</creationTimestamp>
  <creatorType>e-mail</creatorType>
  <creator>joerg.neidig@siemens.com</creator>
  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>
  <lastModifierType>e-mail</lastModifierType>
  <lastModifier>joerg.neidig@siemens.com</lastModifier>
  <signatureType>None</signatureType>
</blockMeta>
<blockMeta blockID="4">
  <blockType>Custom</blockType>
  <contentType>106</contentType>
  <creationTimestamp>1292931142</creationTimestamp>
  <creatorType>e-mail</creatorType>
  <creator>joerg.neidig@siemens.com</creator>
  <lastModifiedTimestamp>1292931142</lastModifiedTimestamp>
  <lastModifierType>e-mail</lastModifierType>
  <lastModifier>joerg.neidig@siemens.com</lastModifier>
  <signatureType>None</signatureType>
</blockMeta>
</metas>
<blocks>
 <coreBlockData blockID="0">
   <version>1.0</version>
   <product_name>S7-MODULAR EMBEDDED CONTROLLER</product_name>
   <product_type>Steuerung</product_type>
   <company_name>Siemens</company_name>
   <part_number>6AV7861-3TB10-1AA0</part_number>
 </coreBlockData>
 <idsBlockData blockID="1">
   <primaryID idType="rfid">4AgBziEDWUQ=</primaryID>
   <id idType="custom">SLBB 1003763</id>
   <id idType="custom">2331</id>
   <id idType="custom">+A1M09</id>
   <id idType="custom">=A1EB2-X2</id>
 </idsBlockData>
 <customBlockData blockID="2">
   <namespace>ecl@ss</namespace>
   <rdf:RDF xmlns:gr="http://purl.org/goodrelations/v1#" xmlns:foo="http://www.mystore.com/semanticweb/"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:eco="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
     <eco:C_AKF303003-gen rdf:about="http://www.mystore.com/semanticweb/myPencil">   
     <eco:P_BAF559001> <gr:QuantitativeValueFloat rdf:about="http://www.mystore.com/semanticweb/QuantitativeValueFloat_1">
     <gr:hasUnitOfMeasurement rdf:datatype="http://www.w3.org/2001/XMLSchema#string">MMT</gr:hasUnitOfMeasurement> 
     <gr:hasValueFloat rdf:datatype="http://www.w3.org/2001/XMLSchema#float">150.0</gr:hasValueFloat> 
     </gr:QuantitativeValueFloat> </eco:P_BAF559001>
     <eco:P_BAG073001 rdf:resource="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#V_BAC386001" /> 
     </eco:C_AKF303003-gen> 
   </rdf:RDF> 
</blocks>
<customBlockData blockID="3">
<namespace>siemens.maintenance.comos</namespace>
øš�dj^‰J1‡ûgè·ÑWá�ÕÏ -·e¥��¨í+µ^N+2vµœiÕKÜ—Š—¡A/¡
Áï¥[Gtñ&ö‡-}R²ÒtùÉuT)µ*Ò^‰Tp^í�oÞñÚ¶�çië;wT¥ã´ÝVέ•Å?=:q–=8d“Kn߆���iõŒðŒÛ:ÍÅ?�£_ÔúU©¶ñ�oY¨óKÑ	¨Tÿ `ýæO++°þq8±ïøe¿÷�ÕÔãË?£_U²ªñ…'	´¤½
$ס£öóÀ_^¾��;kT¹¯ãµ­2�J56ÞdëÑI)ËÓ:nœß¦lœW”ól  Û›Yøåô@xkàýÄ+½›¹lµúÚ­µ*U§=>Ò•J\µ"¥�9U‹Î�˜±<�ü#¶·„ÖÒ¿Ü[N†£oae{+
‘ÔèÆ•GQB�m(ÎK�©�¹óŸ”ßE�õÝkßê�_ÔÄÛÿ  ÿ úß÷_ñš¯ö[s2í»5–÷ 
0¢<#|2v/ƒ�«£iûº×X¸¯ªÑz�L¶§V*0’‹ææ©�<µç>ø9xcìo 
OZ±Ú6ºÅ½m&:×�T·…$ã6Òåå©,¼Åù&ú1ÿ «Î�ÿ  ]?Y�ŸÐoý[q'ø>Óúʆs¶ñ1–öøFxPm��
�HÔ÷m¾§qoªW½�¦P…Y)F<Ï™JqÂǺ~g}�_��‘áE¤lËm£k«ÛÔÑëÝT¸z¥¼)&ªFš/,åŸ`óœw�¡^�Þ	_]žÛÛÚWÕOÔ·Ò›º—
;é?ªüo49yqãiòã·9gæ7†W/Ö“¦í¿«�ªŸ§ukÒäúYêO�â”�sãjsgŸÑŒw‹“Ž�/ Ÿ�¯àÏÅÝcsnÊ�ÆŸw¢UÓ©ÇL£�µ�YW¡Q6¥8®\R—\öã¡ú�²þŠ��÷ÞðÐöޝ§îxj�Åõ
>ÞUìhÆš©V¤a�&«6–d²Ò};Ìÿ ���O®³‰�–Ôú£ú˜õ�•SSõ_¨½WÏËV•>NO��gÆç9û\c¯Máá·Ð“õ½â&×Ý>º^¯úIªZê^¥úAâüw‰«�œœÞ©|¹åÆpñžÆI–¹cÍú�Q\vðÔáWƒÝz–�^wšì#Íô—  
I‡ª.—›™eF›}0§(å<¢=áõá!uàéÁ�·:-XÓÝ:åg§iµ�m¾bÝJéwòG³öÓ†r²Çî�pwyøNq>;?AæÔ5«×;»ÝBþ¬œ(ÙxÊõªuxÌ—^­¹$²ÙmfLî·ó\ú2z�½Ìã£ðÊþúÝ?&wº´-¦×¦1 
¥Q/»ôc6ÕÍ8ëœ>Ö4Ú�ÙÔ±½¥u(û‘’§Ÿ„éÚÿ AÏlP±§õEÄ�Vòñ¤çô²Ò
i÷¥ÏÎß»ÓÜD{Š�
</blocks>
<customBlockData blockID="4">
 <namespace>siemens.maintenance.log</namespace>
   #5;20110303-1230;2234363 ("Müller");"cleaning";"";
   #4;20100203-0911;2234363 ("Müller");"inspection";"ok";
   #3;20100113-0900;765473888 ("Peters");"repair";"fixed";
   #2;20100112-1432;3526317 ("Maier");"inspection";"nok"; "Klappergeräusche"
</blocks>
</spm:semprom>


Integration of other product information standards

Other product information standards like ecl@ss, ETIM or PROLIST are supported 1:1. The respective information can be put without change into a DataBlock.