D2.3 System Architecture Infrastructure Design v2

download D2.3 System Architecture Infrastructure Design v2

of 24

Transcript of D2.3 System Architecture Infrastructure Design v2

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    1/24

    System Architecture /Infrastructure Design

    Person responsible / Author: Moritz von Stietencron - BIBA

    Deliverable No.: D2.3

    Work Package No.: 2

    Date:04.10.2013

    Project No.: 286885

    Classification: PU - Public

    Distribution: To

    File name: D2.3 System Architecture Infrastructure Design V0.4.Docx

    Number of pages: 24

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    2/24

    286885 BOMA

    2

    Status of Deliverable

    Action By Date (dd.mm.yyyy)

    Submitted (author(s)) Moritz von Stietencron

    Karl Hribernik

    04.10.2013

    VU (WP Leader)

    Approved (QIM)

    Revision History

    Date (dd.mm.yyyy) Version (version revision) Author Comments21.02.2013 0.1 Moritz von Stietencron

    Karl HribernikDraft TOC

    26.02.2013 0.2 Moritz von StietencronKarl Hribernik

    TOC revised;Draft Contents

    10.04.2013 0.3 Moritz von Stietencron Contents updated23.04.2013 0.4 Moritz von Stietencron

    Karl HribernikTOC revised;Contents updated

    15.05.2013 0.5 Moritz von Stietencron Contents updated20.05.2013 0.6 Moritz von Stietencron Contents updated28.05.2013 0.7 Moritz von Stietencron

    Karl HribernikContents updated

    12.07.2013 0.8 Moritz von StietencronKarl Hribernik

    Contents updated

    05.08.2013 0.9 Moritz von StietencronKarl Hribernik

    Contents updated

    26.08.2013 0.10 Moritz von Stietencron Contents updated24.09.2013 0.11 Moritz von Stietencron Contents updated27.09.2013 1.0 Moritz von Stietencron Final Changes

    Author(s) contact information

    Name Organisation E-mail TelKarl Hribernik BIBA [email protected] +49 421 218 50108Moritz von Stietencron BIBA [email protected] +49 421 218 50117

    mailto:[email protected]:[email protected]:[email protected]:[email protected]
  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    3/24

    286885 BOMA

    3

    Table of Contents

    1. INTRODUCTION.......................................................................................................................................... 5 2. BOMA SYSTEM ARCHITECTURE .................................................................................................................. 5

    2.1. INTERACTIONCHANNELS ANDLCM APPLICATIONFRAMEWORK ............................................................................. 5 2.2. SEMANTICMIDDLEWARE ANDDATA SOURCES .................................................................................................... 8

    3. BOMA INFRASTRUCTURE DESIGN .............................................................................................................11

    3.1. ELEMENTS OF THEBOMA INFRASTRUCTURE .................................................................................................... 11 3.2. REQUIREMENTS FULFILLED BYBOMA INFRASTRUCTURE ..................................................................................... 14

    FiguresFigure 1: BOMA System Architecture Overview ......................................................................................... 5Figure 2: BOMA System Architecture Interaction Channels & LCM Application Framework .................. 6Figure 3: BOMA Mock Up Overview ........................................................................................................... 7Figure 4: BOMA Mock Up Production Sheet List ........................................................................................ 8Figure 5: BOMA Mock Up Activity Detail .................................................................................................... 8Figure 6: BOMA Semantic Middleware and Data Sources .......................................................................... 9Figure 7: Semantic Mediator....................................................................................................................... 9Figure 8: BOMA UMG Structure ................................................................................................................ 10Figure 9: Exemplary UMG PC - "BeagleBone" ........................................................................................... 10Figure 10: Exemplary BOMA Infrastructure .............................................................................................. 11

    Tables

    Table 1: List of BOMA Infrastructure Components ................................................................................... 11Table 2: List of BOMA Technical Requirements ........................................................................................ 14

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    4/24

    286885 BOMA

    4

    Abbreviations and Acronyms:DSS Decision Support SystemLMS Lifecycle Management ServerBOW BOat Web application

    LCM Life Cycle ManagementQLM Quantum Lifecycle ManagementNMEA National Marine Electronics Association

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    5/24

    286885 BOMA

    5

    1. Introduction

    The BOMA WP2 Boat Lifecycle Management Infrastructure design analyses the requirements putforward in the previous WPs and from these requirements designs the infrastructure and the services thatwill be proposed by the SMEs to their customers. Building on the structured analysis and merging of thedifferent requirements from the SMEs and the definition of the pilot cases which both has beendocumented in deliverable "D2.1 Requirements catalogue and pilot definition", this deliverable documentsthe developed system architecture and the infrastructure design developed in BOMA.

    The deliverable is structured in two parts. The first will show the general system architecture, requiredfor the BOMA solution, while the second will show the infrastructure utilised for this architecture in moredetail.

    2. BOMA System Architecture

    Based on the requirements which were identified in task 2.1 and the pilot cases built upon theserequirements in task 2.2 this deliverable documents the development and specification of the BOMA

    System Architecture as conducted in task 2.5.The BOMA system architecture consists of the following four layers: the Interaction Channels, the LCM

    Application Framework, the Semantic Middleware and the Data Sources.

    Figure 1: BOMA System Architecture Overview

    Figure 1 gives an overview of the arrangement of the different layers within the BOMA systemarchitecture while the following sections describe the layers in more detail.

    2.1. Interaction Channels and LCM Application FrameworkThe interaction channels are the means of access for all the different types of users to the Life Cycle

    Management (LCM) application framework.

    Semantic Mediator

    Stakeholder Data Source 1

    Stakeholder Data Source 2

    Stakeholder DataSource n

    Universal MarineGateway 1

    On-boardSensor 1

    On-boardSensor 2

    On-boardSensor n

    Universal MarineGateway 2

    Universal MarineGateway n

    TelediagnosticBus

    On-board data sourcesBack-end data sources

    WebServices

    3d party Internet data sources

    Configuration ServicesQuery Services

    Boat Management Application Framework

    LCMModules

    CloudServices

    SocialNetworkServices

    Boat/data sourcedatabase

    Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper

    ProductionModules

    ServiceModules

    CRMModules ...

    Semantic Middleware

    Data Sources

    LCM Application Framework

    Interaction Channels

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    6/24

    286885 BOMA

    6

    Possible interaction channels are: On-board (Touch-)Screens of existing Systems Owners Smartphone or Tablet or Laptop-computer PDAs or Tablets used in the production and maintenance processes Computers used for production and maintenance planning and control

    Computers used in pre- and after-sales service Any web-enabled device

    Figure 2: BOMA System Architecture Interaction Channels & LCM Application Framework

    In BOMA the HOLONIX i-LiKe platform provides the application framework of the BOMA systemarchitecture. It offers various modules for different business departments (e.g. Design, Production,Warehousing and Maintenance). These modules support the management of many data and informationthroughout the item lifecycle, from the bill of material (as-designed, as-customized and as-produced),design documents and customer complaints to usage data, and maintenance history

    In WP2 the i-LiKe platform was adopted towards the requirements of the leisure boating industry. Toimprove the understanding within the project team and the usability of the solution first a software mock-up has been built for studying, testing and display. The mock up also helped to verify the fulfilment of therequirements imposed by the SMEs involved in the project.

    Within i-LiKe a BOMA product item mock-up was created. Figure 3 shows an example of the overview

    page while Figure 4 and Figure 5 display exemplary detail pages.

    Boat Management Application Framework

    LCMModules

    ProductionModules

    ServiceModules

    CRMModules ...

    LCM Application Framework

    Interaction Channels

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    7/24

    286885 BOMA

    7

    Figure 3: BOMA Mock Up Overview

    The product item in BOMA platform identifies a single physical product already manufactured anddelivered to the market. It is the virtual representation of a real boat, its avatar. The BOMA solution is alsosusceptible for retrofitting into the existing boat population, having a faster impact and providing businessbenefits to all parties involved in the value chain.

    The product item comes from the product type already defined into the system. A product typeidentifies a particular model of the range. Before the product type is being sent into production it can becustomised according to the users requirements, creating a customised bill of material. As soon, as thecustomised product type is completely defined it can be sent into production, turning into a new productitem. The details of a selected item are shown in a pop-up page where are recorded all the data gatheredwithin the whole lifecycle. All the information need by the shipyard or desired by boat-owner are accessiblethrough this page. In particular:

    Production Sheet related to the Product Item A complete and updated list of all activities done on that item through the entire lifecycle (e.g.

    service and maintenance activities etc.) List of the sensors installed on board. Selecting one or more, users can visualize or download

    recorded data, stored in suitable formats List of manuals of equipment and components assembled on the boat. They support boat

    owner in self-maintenance and other simple activities Picture of the Product item for a faster identification All the changes occurred during production and parts and components replaced during the

    usage.

    The system, if required, can also keep the log of the boat owners, tracing also these additional details.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    8/24

    286885 BOMA

    8

    Figure 4: BOMA Mock Up Production Sheet List

    Figure 5: BOMA Mock Up Activity Detail

    2.2. Semantic Middleware and Data SourcesThe semantic middleware utilised in BOMA builds the infrastructure layer for integrating the various

    data sources. It integrates the various data sources and presents the data requested to the boatmanagement application framework (i.e. the HOLONIX i-LiKe Platform).

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    9/24

    286885 BOMA

    9

    Figure 6: BOMA Semantic Middleware and Data Sources

    At the heart of the semantic middleware stands the semantic mediator. The semantic mediatorintelligently integrates heterogeneous systems, standards, schemata and data exchange formats (seeFigure 7) . It is capable of extracting knowledge regarding the data structures of the underlying data sourcesand subsequently transforming, decomposing and recomposing data requests according to that knowledge.The mediator relies on semantic descriptions of the data sources

    The application framework can access the semantic mediator through a query service, which thesemantic middleware includes. Via a configuration service the semantic mediator can be initialised to readand interpret the varying data sources. Because of this dynamic configuration service the semanticmediator also provides a suitable integration mechanism for dynamic data sources like RFID and sensors.

    Figure 7: Semantic Mediator

    As the semantic mediator builds on a distributed system the processed data remains where it isgenerate. It integrates the data sources at a semantic, not only syntactic level. The automation of theintegration is possible via (semi-) automatic ontology mapping. It allows semantic integration of sensor datawith enterprise systems and thus the reasoning upon the automatically integrated data.

    The concept of the semantic mediator makes it necessary to use a semantic data model for productlifecycle management (i.e. the PROMISE Object Model) and a simple management of stakeholder datasources per boat. The preparation of QLM wrappers/query interface for UMG/iLike integration is also aprerequisite for the utilisation of the semantic mediator.

    The data sources within the BOMA scope that feed the semantic mediator through their respective

    wrappers are grouped into three sections: Back-end Data Sources, On-board Data Sources &

    Semantic Mediator

    Stakeholder Data Source 1

    Stakeholder Data Source 2

    Stakeholder DataSource n

    Universal MarineGateway 1

    Universal MarineGateway 2

    Universal MarineGateway n

    On-board data sourcesBack-end data sources

    WebServices

    3d party Internet data sources

    Configuration ServicesQuery Services

    CloudServices

    SocialNetworkServices

    Boat/data sourcedatabase

    Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper

    Semantic Middleware

    Data Sources

    Semantic Mediator

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    10/24

    286885 BOMA

    10

    3 rd Party Internet Data Sources.The Back-end data sources are the already existing systems of the different stakeholders (e.g.

    production planning systems, customer relationship management systems and warehousing systems).The on-board data sources represent the data coming from different systems on the boats. They are

    sourced and aggregated by the Universal Marine Gateway (UMG) which is also developed within BOMA and

    described in the following section.The 3 rd party internet data sources are online services which can provide for example weather forecastsand other 3 rd party data which is of interest to the stakeholders.

    The Universal Marine Gateway (UMG, see Figure 8) provides data collection, storage, and filtering andserves as a gateway to on-board sensors as well as to 3rd party, on-board data sources (e.g. the NMEAstandard). It also is the communication gateway between the boat and the boat management applicationframework (i.e. the HOLONIX i-LiKe Platform).

    Figure 8: BOMA UMG Structure Figure 9: Exemplary UMG PC - "BeagleBone"

    The key component of the UMG is a single-board computer. It is a full linux PC and offers wired as wellas wireless connectivity. In addition to easy sensor integration it has a low cost factor and is easilyextendable. The BeagleBone computer shown in Figure 9 is an excellent example of such an computer.

    The on-board sensors are required to measure the usage data (e.g. running conditions, componentstress and integrity). Like the UMG PC they should preferably be low cost.

    Universal MarineGateway 1

    On-board

    Sensor 1

    On-board

    Sensor 2

    On-board

    Sensor n

    Universal MarineGateway 2

    Universal MarineGateway n

    TelediagnosticBus

    On-board data sources

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    11/24

    286885 BOMA

    11

    3. BOMA Infrastructure Design

    The BOMA infrastructure comprises a number of elements, which enable it to host the architecturedescribed earlier in this deliverable. These elements are described in the following subsection and aremapped to the technical requirements, they support.

    Figure 10: Exemplary BOMA Infrastructure

    Figure 10 gives an overview of a wide range of exemplary elements of the BOMA infrastructure andtheir connection with each other. As stated before the central connection point of the boat and theonshore parts of the BOMA architecture is the UMG. It connects the different pre-existing (e.g. NMEA 2000hardware) and additional sensors and systems with the respective instances of the i-Like system.

    3.1. Elements of the BOMA InfrastructureThe BOMA infrastructure includes the following elements, in order to fulfil the technical requirements,

    which were identified in D2.1. This list describes the setup of the BOMA infrastructure including allcomponents envisioned during the requirements analysis. Not all are necessarily needed to conduct theBOMA pilot cases and for other application scenarios further components might be necessary.

    Table 1: List of BOMA Infrastructure Components

    Universal Marine Gateway (UMG)fulfils req. #12,13,15,16,18-20,23,26,28-30,33,35,42-44,46,49,51,53,54,58,65,69,126,127,

    135,138,139,143-146,148,149,152-154,166,170,177,178,183,185,186,208,210,212,218

    The UMG is one of the two centrepieces of the BOMA infrastructure. It combines all thedata which is provided by the different sensors and interfaces (i.e. NMEA) on-board andaggregates it for further use in the i-LiKe system. It therefore is necessary for fulfilling alarge number of technical requirements. Also it is used to process the sensor datagenerated in the production process.

    C1

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    12/24

    286885 BOMA

    12

    RFID PDAfulfils req. #2,13,21,22,28,31,32,34,49,51,60,63,147,148,150-153,181,185,194,196,

    208,215,217The RFID PDA is used for part identification in the context of production as well as inmaintenance, storage and repair. The RFID PDA is the key interaction channel of the

    personnel to the BOMA LCM Management Application.

    C2

    RFID Tagsfulfils req. #2,28,32,49,60,63,147,148,152,153,196,208,217The RFID Tags identify the boat components they are attached to. Thus they can alsoidentify the whole boat.

    C3

    NMEA Gateway (UMG compliant) fulfils req. #12,13,15,16,18-20,23,26,30,33,49,135,139,144,152,166,183,208,218The NMEA Gateway connects the UMG to the NMEA bus on board of the boat. This isnecessary in order to acquire and integrate the data, which is already pre-existing in the

    on-board systems, like engine management or gearbox control.

    C4

    Water Temperature Sensor fulfils req. #89,89.3,144,154,178The water temperature sensor measures the surrounding waters temperature and deliversthis data to the UMG, which can process and include it in the BOMA data set.

    C5

    Air Temperature Sensorfulfils req. #28,89,89.2,144,146,148,149,154,178In the case of on-board deployment, the air temperature sensor measures thetemperature of the surrounding air and delivers this data to the UMG, which can process

    and include it in the BOMA data set. The air temperature is also important for theproduction environment and therefore this sensor will also be applied to the productionUMGs.

    C6

    Humidity Sensorfulfils req. #28,89,89.1,144,145,148,149,154,178In the case of on-board deployment, the humidity temperature sensor measures thehumidity of the surrounding air and delivers this data to the UMG, which can process andinclude it in the BOMA data set. The air humidity is also important for the productionenvironment and therefore this sensor will also be applied to the production UMGs.

    C7

    Barometric Pressure Sensorfulfils req. #89,144The barometric pressure sensor measures the barometric air pressure and delivers thisdata to the UMG, which can process and include it in the BOMA data set.

    C8

    Ambient Light Sensorfulfils req. #89,144The ambient light sensor measures the ambient light and delivers this data to the UMG,which can process and include it in the BOMA data set.

    C9

    Accelerometer

    fulfils req. #6,12,43,44,154,178,186The accelerometer measures the proper acceleration of the boat, which can for examplebe expressed in g-force units. It delivers this data to the UMG which processes it and

    C10

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    13/24

    286885 BOMA

    13

    includes it in the BOMA data set. This data can be used to assess the performance andcondition of the boat.

    Gyroscope fulfils req. #6,12,154,178

    While the accelerometer measures the acceleration, the gyroscope determines andmaintains the orientation of the boat. It also delivers this data to the UMG whichprocesses it and includes it in the BOMA data set. This data can be used to assess theperformance and condition of the boat.

    C11

    Strain Gaugefulfils req. #6,42-44,127,143,186A strain gauge measures the strain in a material. It uses the physical property of electricalconductance and its dependence on the conductor's geometry and delivers informationabout changes in geometry of the considered area. This data is processed in the UMG andincluded in the BOMA data set, so it can be used for assessing the boat hulls condition and

    enable the assessing of its integrity.

    C12

    WiFi Modulefulfils req. #28,46,53,54,58,69,212,221The WiFi module will be attached to the UMG and enable wireless communication. Thiscan be utilised in the case of on-board usage to establish connectivity with the boatowners smart phone, the maintenance crews systems or when the boat is in a marina withthe local WiFi network in order to communicate with the backend system. In theproduction environment it serves to integrate the UMG into pre-existing or dedicated WiFinetworks and the attached IT systems.

    C13

    WWAN Modulefulfils req. #46,53,54,58,69,224The WWAN module enables wireless communication based on standards like GSM, UMTSor LTE without a separate device as an access point to the internet. This is especiallyimportant for automated transmission of live performance data.

    C14

    Satellite Communication Modulefulfils req. #46,53,54,58,69,202The satellite communication module enables over-the-air communication from locationswhere no WiFi or cellular network is available. This secures the possibility to access livedata from any operating location and gives the possibility of emergency message dispatch.

    C15

    XBee UMG Shieldfulfils req. #89The XBee shield will be attached to the UMG and empowers it to communicate over astable, medium range, wireless connection with sensors which can be distributed acrossthe boat without the need for wired connection.

    C16

    XBee Sensor-Nodes fulfils req. #89The XBee sensor nodes, are the counterpart to the XBee UMG shield and allow the sensorsattached to them to communicate with the UMG.

    C17

    GPS Receiver fulfils req. #32,135,138,166

    C18

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    14/24

    286885 BOMA

    14

    The GPS receiver enables the UMG to determine the position of the boat via the globalpositioning system. In the future, this receiver may also use the data from the Galileopositioning system.

    i-LiKe Instance

    fulfils req. #16-23,26,28-34,42,49,51,53,54,58,128,132,147,148,150,154,166,169,170,181,184,185,192-194,196,208The i-LiKe installation is the second centrepiece of the BOMA solution. It constitutes theBOMA Life Cycle Management Application Framework described in Section 2.1.

    C19

    WiFi @ Marina & Workshop fulfils req. #28,46,53,54,58,69,212,216,221The WiFi network to be established at the marina and at the workshops will be utilised toenable online connectivity of the UMG for data transfer and remote monitoring.

    C20

    Semantic Mediator

    fulfils req. #82,128,132,143,192,216The semantic mediator is the third key part of the BOMA solution. It semanticallyintegrates all data sources considered meaningful to the BOMA solution. It thus enables,that all the different data sources (analog and digital sensors, NMEA data etc.) can becombined and compared.

    C21

    Owners Smartphonefulfils req. #46,53,54,58,69,135,138,194,212,215,216,224The Owners smart phone can be used as a gateway to connect the UMG to the internetwhen the boat is out of range of WiFi networks. It may also serve as a separate interactionchannel for the boat owner.

    C22

    3.2. Requirements fulfilled by BOMA InfrastructureThis section lists the requirements which are fulfilled by the utilisation of the BOMA infrastructure

    components described in section 3.1 and shows exactly which components are important for the respectiverequirement.

    Table 2: List of BOMA Technical Requirements

    Allocation of UID to Part #2Technical Requirement - Stakeholders: Fiart Mare, Marex

    Fulfilled by infrastructure components C2,3The allocation of the unique identifier (UID) to the boats part is achieved via RFID tags andthe RFID enabled PDAs.

    Assess Hull Integrity #6Technical Requirement - Stakeholders: Hydrolift, KarnicFulfilled by infrastructure components C10,11,12The integrity of the boats hull is assessed via the measurements of the accelerometer,gyroscope and the strain gauges.

    Collect Boat Performance Data #12

    Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C1,4,10,11Data about the performance of the boat is gathered via the NMEA gateway, the

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    15/24

    286885 BOMA

    15

    accelerometer and the gyroscope and is processed in the UMG.

    Collect Component Data #13Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,2,4

    The collection of the component data is achieved by the NMEA gateway, the UMG and thePDAs.

    Collect Data on Boat when in Use #15Technical Requirement - Stakeholders: Fiart Mare, Hydrolift, Karnic, Marex, MarineCenterFulfilled by infrastructure components C1,4For collecting data on the boat, while it is in use, the UMG and the NMEA gateway are used.

    Collect Drive Train Data #16Technical Requirement - Stakeholders: Marine Center

    Fulfilled by infrastructure components C1,4,19The drive train data is collected by the UMG from the NMEA gateway and passed on to thei-Like instance.

    Collect EOL Data #17Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C19The EOL data is collected by the i-Like instance.

    Collect Engine Data #18Technical Requirement - Stakeholders: Marine Center

    Fulfilled by infrastructure components C1,4,19The engine data is collected from the NMEA gateway by the UMG and passed on to the i-Like instance.

    Collect Fuel Filter Data #19Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19The fuel filter data is collected from the NMEA gateway by the UMG and passed on to the i-Like instance.

    Collect Gearbox Data #20Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19The gearbox data is collected from the NMEA gateway by the UMG and passed on to the i-Like instance.

    Collect Genset Data #21Technical Requirement - Stakeholders: marine CenterFulfilled by infrastructure components C1,19Information about the genset is entered via the PDAs and processed in the i-Like instance.

    Collect Heads Data #22Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C2,19

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    16/24

    286885 BOMA

    16

    Information about the heads is entered via the PDAs and processed in the i-Like instance.

    Collect House Battery Data #23Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19

    The house battery data is collected from the NMEA gateway by the UMG and passed on tothe i-Like instance.

    Collect Outboard Engine Data #26Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19The outboard engine data is collected from the NMEA gateway by the UMG and passed onto the i-Like instance.

    Collect Production Data #28Technical Requirement - Stakeholders: Karnic, Marex

    Fulfilled by infrastructure components C1,2,3,19The data from the production processes is collected by the UMG from the temperature andhumidity sensors as well as from the RFID PDAs and the RFID tags. The data is transferredvia the WiFi shield on the UMG and the WiFi network at the production site to the i-Likeinstance.

    Collect Propeller Data #29Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,19The propeller data is collected by the UMG and passed on to the i-Like instance.

    Collect Pump Data #30Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19The pump data is collected from the NMEA gateway by the UMG and passed on to the i-Likeinstance.

    Collect Safety Gear Data #31Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C2,19Information about the safety gear is entered via the PDAs and processed in the i-Likeinstance.

    Collect Shipment Information #32Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2,3,18,19Data about the shipment status is collected by the RFID PDAs, the tags and the GPS sensor.It is processed in the i-Like instance.

    Collect Starter Battery Data #33Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4,19The starter battery data is collected from the NMEA gateway by the UMG and passed on tothe i-Like instance.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    17/24

    286885 BOMA

    17

    Collect Thru-Hull Fittings Data #34Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C2,19Information about the thru-hull fittings is entered via the PDAs and processed in the i-Likeinstance.

    Continue Data Collection when not in Use #35Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1For continuing the data collection while the boat is in use, the UMG is implemented.

    Define Stress Hotspots #42Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,12,19The stress hotspots are defined from the data read by the strain gauges and processed byUMG and i-Like instance.

    Determine Energy Effect #43Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,10,12The energy effect is determined from the readings of the strain gauges and theaccelerometer and processed by the UMG.

    Determine Force Effect #44Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,10,12The force effect is determined from the readings of the strain gauges and the accelerometerand processed by the UMG.

    Enable Automated Transmission #46Technical Requirement - Stakeholders: Hydrolift, Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1,13,14,15,20,22To enable automated transmission, the UMG and WiFi, WWAN and SatelliteCommunication Modules can be used. Also the data can be transferred via the WiFinetwork or the owners smart phone.

    Enable Boat Components Traceability #49Technical Requirement - Stakeholders: Fiart Mare, MarexFulfilled by infrastructure components C1,2,3,4,19The traceability of the boat components is enabled by the UMG, the RFID PDAs, the RFIDtags, the NMEA gateway and the i-Like instance.

    Enable Data Logging & Saving #51Technical Requirement - Stakeholders: Hydrolift, Fiart Mare, Karnic, Marex, MarineCenterFulfilled by infrastructure components C1,2,19Data logging and saving will be accomplished by the UMG, the RFID PDAs and the i-Likeinstance.

    Enable Event Data Transmission #53Technical Requirement - Stakeholders: Hydrolift, Marex

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    18/24

    286885 BOMA

    18

    Fulfilled by infrastructure components C1,13,14,15,19,20,22Event data transmission is enabled by the UMG, the WiFi, WWAN and Satellitecommunication modules, WiFi networks and the owners smart phone, as well as the i-Likeinstance.

    Enable Manual Transmission #54Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1,13,14,15,19,20,22Manual data transmission is enabled by the UMG, the WiFi, WWAN and Satellitecommunication modules, WiFi networks and the owners smart phone, as well as the i-Likeinstance.

    Enable Operating Data Transmission #58Technical Requirement - Stakeholders: Hydrolift, Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1,13,14,15,19,20,22Operating data transmission is enabled by the UMG, the WiFi, WWAN and Satellite

    communication modules, WiFi networks and the owners smart phone, as well as the i-Likeinstance.

    Enable Part Identification #60Technical Requirement - Stakeholders: Fiart Mare, Karnic, Marex, Marine CanterFulfilled by infrastructure components C2,3Part identification is enabled by the RFID PDAs and the RFID tags.

    Enable UID Readability #63Technical Requirement - Stakeholders: Fiart Mare, MarexFulfilled by infrastructure components C2,3

    UID readability is enabled by the RFID PDAs and the RFID tags.

    Enable Wired Transmission #65Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1For wired data transmission the UMG is necessary.

    Enable Wireless Transmission #69Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1,13,14,15,20,22Wireless data transmission is enabled by the UMG, the WiFi, WWAN and Satellitecommunication modules, WiFi networks and the owners smart phone.

    Establish Data Interface Syntax #82Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C21The semantic mediator establishes the data interface syntax.

    Implement Environmental Sensors #89Technical Requirement - Stakeholders: Hydrolift, Karnic, MarexFulfilled by infrastructure components C5-9,16,17As environmental sensors the following are implemented: Water temperature, airtemperature and humidity. For wireless integration the XBee sensor-nodes and the XBeeUMG shield are required.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    19/24

    286885 BOMA

    19

    Monitor Air Humidity #89.1Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,7To monitor the air humidity the UMG and the humidity sensor are required.

    Monitor Air Temperature #89.2Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,6To monitor the air temperature the UMG and the air temperature sensor are required.

    Monitor Water Temperature #89.3Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,5To monitor the water temperature the UMG and the water temperature sensor arerequired.

    Install On-Board Computer #126Technical Requirement - Stakeholders: Fiart Mare, Hydrolift, Karnic, Marex, MarineCanterFulfilled by infrastructure components C1The UMG is the on-board computer.

    Install Stress Sensors #127Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,12To install stress sensors, the UMG and the strain gauges are required.

    Integrate with Existing Enterprise Systems #128Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C19,21To interoperate with existing enterprise systems, the i-Like instance and the semanticmediator are required.

    Interoperate with SAP #132Technical Requirement - Stakeholders: Fiart MareFulfilled by infrastructure components C19,21To interoperate with SAP, the i-Like instance and the semantic mediator are required.

    Log GPS Position #135Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,4,18,22To log the GPS position the UMG, the NMEA gateway, a GPS receiver and the owners smartphone can be used.

    Measure "Down-Time" #138Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,18,22To measure the down-time, the UMG, a GPS receiver and the owners smart phone can beused.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    20/24

    286885 BOMA

    20

    Measure Engine Wear #139Technical Requirement - Stakeholders: Marine CenterFulfilled by infrastructure components C1,4To measure the engine wear the UMG and the NMEA gateway can be utilised.

    Measure Waves #143Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,12,21To measure the wave intensity the data from strain gauges and accelerometer are gatheredvia the UMG and combined with online marine weather data and wave informationprovided by the semantic mediator.

    Measure Weather #144Technical Requirement - Stakeholders: HydroliftFulfilled by infrastructure components C1,4-9To measure the parameters of the current weather the UMG gathers data from sensors

    measuring water temperature, air temperature, barometric pressure, humidity and ambientlight. Some data might be gathered via the on-board NMEA bus.

    Monitor Air Humidity #145Technical Requirement - Stakeholders: Karnic, MarexFulfilled by infrastructure components C1,7The air humidity is measured via a humidity sensor and processed by the UMG.

    Monitor Air Temperature #146Technical Requirement - Stakeholders: Karnic, MarexFulfilled by infrastructure components C1,6The air temperature is measured via a humidity sensor and processed by the UMG.

    Monitor Components #147Technical Requirement - Stakeholders: Karnic, Marex, Marine CanterFulfilled by infrastructure components C2,3,19The components are monitored throughout the production using RFID tags and the RFIDPDA. The data is processed in the i-Like instance.

    Monitor Composite Parts #148Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1-3,6,7,19The composite parts are tracked thro throughout the production using RFID tags and theRFID PDA, while the environmental conditions of the composite part production ismonitored via air temperature and humidity sensors, which are managed by a UMG. Thedata is processed in the i-Like instance.

    Display Hull Mixing Ratio #149Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,6,7The mixing ratio of resin and catalyst for the composite parts is calculated by the UMG andbased on the data from the humidity and temperature sensors.

    Monitor Man Hours per Stage #150Technical Requirement - Stakeholders: Karnic

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    21/24

    286885 BOMA

    21

    Fulfilled by infrastructure components C2,19The man hours used per stage are monitored by the PDAs and the data is processed in the i-Like instance.

    Monitor Material #151

    Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2The material used can be monitored using the PDAs.

    Monitor Optional Equipment #152Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1-4Optionally installed equipment can be monitored either via RFID tags and the PDA or via theUMG and the NMEA gateway if the parts are connected to it.

    Monitor Parts & Accessories #153

    Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1-4The parts and accessories can be monitored either via RFID tags and the PDA or via theUMG and the NMEA gateway if the items are connected to it.

    Monitor Working Conditions #154Technical Requirement - Stakeholders: Karnic, MarexFulfilled by infrastructure components C1,5-11,19The working conditions of the boat are monitored by i-Like based on the data gathered bythe UMG and provided by the different sensors.

    Provide Availability Information #166Technical Requirement - Stakeholders: Fiart MareFulfilled by infrastructure components C1,4,18,19The UMG can process the data from the GPS receiver (in some cases via the NMEAgateway) and forward it to the i-Like instance where the availability information can beprovided.

    Provide Boat Service Schedule #169Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C19The boats service schedule can be computed by the i-Like instance.

    Provide Dynamic Database #170Technical Requirement - Stakeholders: Fiart MareFulfilled by infrastructure components C1,19The main dynamic database is provided by the i-Like instance. Also the UMG has a limitedsize database to buffer and store some more recent data.

    Provide On-Board Data Processing #177Technical Requirement - Stakeholders: Fiart Mare, Hydrolift, Karnic, Marex, MarineCanterFulfilled by infrastructure components C1The on board data processing power is provided by the UMG.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    22/24

    286885 BOMA

    22

    Provide Operating Conditions & Performance Data #178Technical Requirement - Stakeholders: Fiart Mare, Hydrolift, Karnic, Marex, MarineCanterFulfilled by infrastructure components C1,5-11Data on the operating conditions and performance is gathered from the various sensors by

    the UMG and provided for further use.

    Provide Production GUI #181Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2,19The graphical user interface of the production system is provided by the i-Like instance anddisplayed on the PDA.

    Provide Sensor-Processor Interface #183Technical Requirement - Stakeholders: Fiart Mare, Hydrolift, Karnic, Marex, MarineCanter

    Fulfilled by infrastructure components C1,4The sensor processor interface is provided by the UMG and the NMEA gateway.

    Provide Service Data #184Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C19The service data is provided by the i-Like instance.

    Provide Service personnel / Operator Interface #185Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C1,2,19

    The interface for the operator and service personnel can be provided by the i-Like instanceand displayed via the PDAs or via the UMG.

    Provide Stress and Impact Information #186Technical Requirement - Stakeholders: Hydrolift, Karnic, Marine CanterFulfilled by infrastructure components C1,10,12The information on stress and impacts can be measured by strain gauges and accelerometerand is processed and provided for further use by the UMG.

    Provide XML Input & Output #192Technical Requirement - Stakeholders: Fiart MareFulfilled by infrastructure components C19,21XML input and output can be provided by the i-Like instance and the semantic mediator.

    Provide different Data Views #193Technical Requirement - Stakeholders: Karnic, Marex, Marine CanterFulfilled by infrastructure components C19Different data views will be provided by the i-Like instance.

    Provide different GUI #194Technical Requirement - Stakeholders: Karnic, Marex, Marine CanterFulfilled by infrastructure components C2,19,22Different GUI will be provided by the i-Like instance and can be displayed on the PDAs andthe owners smartphone.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    23/24

    286885 BOMA

    23

    Recognise Change of Ownership #196Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2,3,19A change of ownership can be recognised using the RFID PDAs and RFID tags or the i-Like

    system.

    Satellite Communication #202Technical Requirement - Stakeholders: Fiart Mare, MarexFulfilled by infrastructure components C15Satellite communication is provided by the satellite communication module.

    Track Component Changes #208Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C1-4,19Component changes can be identified and tracked via the RFID PDAs and tags, the i-Like

    instance or the UMG and NMEA gateway.

    USB Interface #210Technical Requirement - Stakeholders: MarexFulfilled by infrastructure components C1The UMG can provide a USB interface.

    Use Customers Smartphone as Data Access Point #212Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,13,22To use the owners smartphone as a data access point, the smartphone it self, a local wificonnection and the UMG are necessary.

    Use Mobile Device Displays #215Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2,22As mobile device displays the PDAs and the owners smartphone can be used.

    Use Texts & EMail for Communication #216Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C20-22To use texts and email for communication the owners smartphone, the semantic mediatorand wifi connection at the marina can be used.

    Use existing Part Identification #217Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C2,3For the use of existing part identification mechanisms the RFID PDAs and tags can beutilized.

    Use onboard Displays #218Technical Requirement - Stakeholders: KarnicFulfilled by infrastructure components C1,4To use existing onboard displays the NMEA gateway and the UMG can be used.

  • 8/13/2019 D2.3 System Architecture Infrastructure Design v2

    24/24

    286885 BOMA

    Wireless LAN #221Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C13,20The WiFi module and the WiFi network at marinas and the workshops will be used toestablish WLAN connectivity.

    Wireless WAN #224Technical Requirement - Stakeholders: Fiart Mare, Karnic, MarexFulfilled by infrastructure components C14,22The WWAN module and owners smartphone can be used to establish WWAN connectivity.