Custodian® Embedded Mobile
Afstudeerdocument
ICT Embedded B.V.
Project Custodian® Embedded Mobile Document ID ICT.CUST.004
Auteur(s) R.L.M. Hermans Status Definitief
Datum 12 juni 2008
Classificatie Algemeen
Versie 1.0
Template ICT2.3003N v2.6
Historie
Versie Datum Auteur Omschrijving
0.1 27-03-2008 Ruud Hermans Initiële versie
0.2 23-05-2008 Ruud Hermans Aangepaste versie na review met Frank 0.3 06-06-2008 Ruud Hermans Aangepaste versie na review met Frank 0.4 11-06-2008 Ruud Hermans Concept volledige versie
1.0 11-06-2008 Ruud Hermans Definitieve versie
Distributie
Versie Datum Aan Bedrijf
0.1 22-05-2008 Frank Fleuren ICT Embedded B.V.
0.2 27-05-2008 Frank Fleuren ICT Embedded B.V.
0.3 09-06-2008 Frank Fleuren, Louis van Gool ICT Embedded B.V. 0.4 11-06-2008 Frank Fleuren, Louis van Gool ICT Embedded B.V. 1.0 12-06-2008 Frank Fleuren, Louis van Gool ICT Embedded B.V.
1.0 12-06-2008 Jan Oostindie, Ellen Kroes Avans Hogeschool
Dit document is eigendom van ICT Embedded B.V. Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke wijze ook, zonder voorafgaande schriftelijke toestemming van de eigenaar.
Afstudeerverslag voor Avans Hogeschool Breda
Gegevens StudentNaam: Ruud Hermans
Studentnummer: 115635
Opleiding: Technische Informatica
Afstudeerperiode: 07-01-2008 t/m 27-06-2008
Duur: 100 werkdagen
Gegevens Bedrijf
Naam: ICT Embedded B.V.
Adres: Science Park Eindhoven 5006
Postcode: 5692 EA
Plaats: Son
Naam procesbegeleider: Frank Fleuren
Functie: Sales Support
Naam technisch begeleider: Louis van Gool
Functie: Consultant
Gegevens docentbegeleider
Naam: Jan Oostindie
Gegevens verslag
Titel: Custodian® Embedded Mobile
Termen en afkortingen
Term Omschrijving
Custodian Systeem dat bedrijven van de mogelijkheid voorziet om op afstand service te verlenen op door hen geleverde machines.
Custodian Embedded Het deelsysteem van Custodian dat op de machine-to-machine hardware communiceert met een apparaat.
Custodian Back Office Het deelsysteem van Custodian waarvan uit communicatie met de Embedded systemen plaats vindt.
Imlet Programma gecompileerd voor gebruik op de Nokia-12i
Afkorting Omschrijving
API Application Programming Interface
CORBA Common Object Request Broker Architecture
CSD Circuit Switched Data
EDGE Enhanced Data rates for GSM Evolution
GIOP General Inter-ORB Protocol
GPRS General Packet Radio Service
HSCSD High-Speed Circuit-Switched Data
HTTP HyperText Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICE Internet Communications Engine
M2M Machine-to-machine
MIB Machine Interface Board
ORB Object Request Broker
PvA Plan van Aanpak
RPC Remote Procedure Call
SMS Short Message Service
UMTS Universal Mobile Telecommunications System
XML Extensible Markup Language
Referenties
Referentie Document ID Omschrijving
Research Document ICT.CUST.001 Onderzoek naar te gebruiken technieken voor Custodian. Software Requirements
Document
ICT.CUST.002 Analyse van eisen aan Custodian.
Architectural Design Document
ICT.CUST.003 Object-georiënteerd ontwerp document voor Custodian.
UML ISBN 0-201-57168-4 The Unified Modelling Language User Guide
Voorwoord
Mijn naam is Ruud Hermans en ik ben ter afronding van een vierjarige Technische Informatica opleiding bezig met mijn afstudeeropdracht bij ICT Embedded B.V. te Son. Dit is het afsluitende document van mijn
afstudeerperiode.
Van iedere student op de opleiding, Technische Informatica aan de Avans Hogeschool te Breda, wordt verwacht dat aan het einde van de leerweg van vier jaar een afstudeerstage van 100 werkdagen wordt doorlopen. Mocht dit laatste onderdeel van de opleiding goed doorlopen worden, dan krijgt de student zijn diploma en het predikaat ‘Bachelor of Information & Communication Technology’.
In het kader van deze afstudeerperiode heb ik een opdracht onder de naam ‘Custodian Embedded Mobile’ uitgevoerd. Hierover zal ik in dit document meer vertellen. Het doel hiervan is om de lezer duidelijk te maken wat de opdracht inhield, hoe ik te werk ben gegaan en wat uiteindelijk mijn resultaten en problemen zijn geweest. Ook zal ik hierin een advies geven over eventuele vervolgopdrachten. Dit document is voornamelijk bedoeld voor de opleiding en het afstudeerbedrijf, om hen te laten zien dat ik een nuttige bijdrage aan het project heb geleverd en ik de juiste competenties heb ontwikkeld om zelfstandig in het bedrijfsleven te functioneren.
Voordat ik hieraan begin wil ik via deze weg eerst een aantal mensen hartelijk bedanken. Allereerst, Tjitske Hartman, dankzij wie ik de afstudeeropdracht bij ICT Embedded B.V. verkregen heb. Zij heeft met mij de eerste gesprekken gevoerd, mij aangenomen en is voor de afstudeerders altijd druk in de weer geweest, ook om de afstudeerperiode zo prettig mogelijk te maken.
Daarnaast Frank Fleuren, die ervoor gezorgd heeft dat mijn periode bij ICT Embedded B.V. vrijwel vlekkeloos verlopen is. Als procesbegeleider heeft hij er perfect voor gezorgd dat ik meteen aan de slag kon, bij
tegenslagen was hij er altijd om me een hart onder de riem te steken en zijn uitgebreide kennis van documenteren en presenteren heeft mij erg geholpen bij het maken van mijn afstudeerdocument en – presentatie.
Ook wil ik Louis van Gool bedanken voor zijn kritische blik en expertise, zonder welke de kwaliteit van mijn opdracht lang niet zo hoog zou zijn. Zijn vermogen om zeer abstract te kunnen redeneren heeft er voor gezorgd dat ik het project ook vanuit een andere visie dan de mijne kon bekijken, waardoor de opdracht zo goed mogelijk uitgevoerd kon worden.
Omdat ze er altijd voor me is en enorm veel geduld heeft opgebracht tijdens mijn schoolcarrière, wil ik ook in het bijzonder mijn vriendin bedanken. Zonder haar was dit nooit gelukt.
Tot slot wil ik alle collega’s bij ICT Embedded B.V, vestiging Eindhoven, bedanken voor een geweldige tijd. Dankzij de informele en gezellige sfeer kwam ik altijd met plezier door weer en file naar mijn werk.
Son, juni 2008 Ruud Hermans
Samenvatting
Vandaag de dag wordt het voor bedrijven steeds belangrijker om werkzaamheden efficiënt uit te voeren. Een reden hiervoor is de wens een goede concurrentiepositie te behalen of te behouden. Vooral op service is een grote voorsprong te behalen. Waar vroeger een technicus nog op locatie machinerie moest onderhouden, is het nu wenselijk om dit op afstand te kunnen. ‘Enterprise Level Remote Assets Management’ is hierdoor een hot item. ICT Embedded is niet achter gebleven bij deze trend en heeft voor het op afstand beheren in 2003 een oplossing ontwikkeld onder de naam Custodian®.
Er zijn echter twee nadelen aan het huidige product. Het eerste is de instabiliteit van de Custodian server. Dit komt omdat het originele systeem niet ontworpen is met het oog op latere toevoeging. In eerdere
afstudeeropdrachten zijn er wel toevoegingen gedaan, waardoor er nu een zodanig complexe code is ontstaan dat deze voor ontwikkelaars moeilijk te overzien en stabiliseren is. Ten tweede hebben in de afgelopen vijf jaar nieuwe technieken de kop op gestoken, die een nieuwe implementatie slimmer, sneller, goedkoper of veiliger kunnen maken. Deze zouden van waarde kunnen zijn voor Custodian®, maar zijn eventueel moeilijk of niet te implementeren in het huidige systeem.
De opdracht van de afstudeerder was voornamelijk gericht op het onderzoek naar deze nieuwe technieken voor de implementatie van Custodian®. Hierbij moest door middel van prototypen de werking en effectiviteit getest worden, zodat op basis van het onderzoek voor een nieuw design gekozen kon worden.
Uit dit design moest een nieuwe implementatie van Custodian® voortvloeien.
De eerste stap in het project was het maken van een Plan van Aanpak. Hierin wordt voor het eerst uitgezet wat de verschillende onderdelen van het project inhouden en hoe deze aangepakt gaan worden.
Op basis van de planning hierin is de rest van het project doorlopen.
Hierna is het Research Document gemaakt. In dit document werd bepaald wat de belangrijke onderdelen van het Custodian® project waren. Aan de hand van ISO standaard 9126: Software Engineering – Product Quality en aan de hand van prototyping werden hierna de gevonden technieken beoordeeld. Zo kon per onderdeel bepaald worden wat de stand van IT op dat gebied was, wat tot innovatie van het Custodian® project geleid heeft. Aan de hand van de resultaten in dit document is door de klant een keuze gemaakt voor de technieken die voor hun doeleinden geschikt waren.
Aan de hand van de gemaakte keuzes in het Research Document is hierna het V-model doorlopen, zoals deze binnen ICT Embedded B.V. toegepast wordt. Hierbij is eerst het Software Requirements Document ontworpen, waarin de eisen aan het Custodian® systeem gesteld werden. Met het gebruik van deze eisen is hierna het Architectural Design Document gemaakt. In dit document wordt de systeemarchitectuur met behulp van UML ontworpen.
Aan de hand van de ontwerpdocumenten is een implementatie gemaakt van het Custodian® Back Office en Embedded systeem. Deze is in Java ontworpen in de Eclipse ontwikkelomgeving. Het Embedded systeem is hierbij geïmplementeerd op de Nokia-12i, een M2M module. Voor de communicatie tussen de Back Office en Embedded systemen is gebruik gemaakt van CORBA over TCP/IP. Uiteindelijk is een systeem voor overdracht van waarden ontstaan, compleet met queue, logging en verschillende manieren om waarden van verschillende bronnen uit te lezen.
Naar aanleiding van het onderzoek en de implementatie tijdens de afstudeerperiode is samenvattend de conclusie van dit project dat het wel degelijk mogelijk is om met de huidige hardware een nieuwe implementatie van Custodian® te ontwerpen, maar dat het bedrijf zich erg goed moet afvragen of dit wel verstandig is met betrekking tot tijd en kosten. De mogelijkheid bestaat dat het optimaliseren van het oude systeem wat tijd en kosten betreft, voordeliger is.
Aan het afstudeerbedrijf is aanbevolen dat, indien er in de toekomst een nieuwe implementatie van het Custodian® project plaats vindt, het in ieder geval van belang dat er eerst nieuwe M2M hardware wordt uitgezocht. Het scheelt niet alleen een hoop ontwikkeltijd, maar vooral veel frustratie voor de ontwikkelaar. Ook is het verstandig om losstaand van het Custodian® project te gaan onderzoeken wat de huidige stand van techniek van berichtprotocollen is.
Summary
These days it has become increasingly important to work efficiently. One reason for this is the wish to maintain a competitive position in the market. Especially on service, a big leap in efficiency is possible. Where previously a technician had to maintain assets on-site, it is now desirable to do this remotely. 'Enterprise Level Remote Assets Management " is a hot item. ICT Embedded picked up on this and in 2003 developed a solution for remote management named Custodian®.
At this time there are two problems with this product. The first one is the instability of the Custodian server. The original system was not designed with additional adjustments and expansion in mind. Regardless, additions were made, creating code so complex that it’s difficult for developers to oversee and stabilize it. Also, in the past five years new techniques have risen that could make a new implementation smarter, faster, cheaper and safer.
The graduate’s assignment was mainly focused on researching these new techniques for the implementation of the Custodian® system. Through prototyping, the performance and operation of these had to be tested, so that based on the research a new design could be picked. From this design a new Custodian® implementation had to be developed.
The project’s first step was to make a Plan of Approach. In this document the different aspects of the project were defined and it was indicated how these would be handled. The remainder of the project progressed according to the schedule in this report.
After this a Research Document was written. In this document the most significant aspects of the Custodian® project were defined. After this, using ISO standard 9126: Software Engineering – Product Quality and prototyping, the chosen techniques were reviewed. Thus could be judged what the state of IT in the area of each aspect was, leading to innovation of the Custodian ® project. Based on the results of this document a choice has been made by the client for the techniques that were suitable for their purposes.
Based on the choices made in the Research Document, the V-model, as applied by ICT Embedded B.V., was followed. The first document designed was the Software Requirements Document, in which the requirements on Custodian® were stated. Using these requirements the Architectural Design Document was written. In this document the system architecture is defined with the use of UML.
These design documents were used to implement the Custodian® Back Office and Embedded systems. This was done in Java, using the Eclipse SDK. The Embedded system was implemented on the Nokia-12i, a M2M module. For communication between the Back Office and Embedded systems, CORBA and TCP/IP were used. Eventually a system for data communication of values was created, fully implemented with the usage of a queue, logging and different approaches to requesting values from different embedded modules.
In conclusion, following the research and implementation during the graduation period, it’s been proved that it’s definitely possible using the current hardware to implement a new Custodian® design. On the other hand, the company really has to question whether this is wise in respect to time and cost. The possibility exists that improving and optimizing the old system would be more advantageous in regards to time and cost.
It was recommended to the company that it is vital new M2M hardware is selected for use, if in the future a new implementation of the Custodian® project is planned. This will not only cut down on production time, but definitely on a lot of frustration for the developer. It is also wise to set up a project independent of Custodian® to research the current state of messaging protocols.
Inhoudsopgave
Inleiding ... 9 1 Afstudeerorganisatie ... 10 1.1 ICT Automatisering N.V. ... 10 1.2 ICT Embedded B.V. ... 11 2 Probleemanalyse ... 12 2.1 Context ... 12 2.2 Probleembeschrijving ... 12 2.3 Doelstelling ... 13 2.4 Randvoorwaarden ... 13 3 Aanpak ... 143.1 Plan van Aanpak ... 14
3.1.1 Projectachtergrond ... 14 3.1.2 Projectbeschrijving ... 14 3.1.3 Projectfasering ... 14 3.1.4 Beheersaspecten ... 14 3.2 Research Document ... 16 3.2.1 ISO 9126 ... 16 3.2.2 Systeemcomponenten ... 17 3.2.2.1 Testopstelling ... 17
3.2.2.2 Communicatie Back Office en Embedded ... 17
3.2.2.3 Connectie M2M ... 19
3.2.2.4 Berichtprotocol ... 20
3.2.3 Keuze ... 22
3.3 Software Requirements Document ... 23
3.3.1 Algemeen... 23
3.3.2 Functional Requirements ... 23
3.3.3 Non-functional Requirements... 23
3.4 Architectural Design Document ... 24
3.4.1 Standaarden ... 24
3.4.2 Use Case View... 24
3.4.3 Design View ... 27
3.4.4 Process View ... 28
3.4.5 Deployment View ... 29
3.4.6 Software architectural construction principles... 29
3.4.7 Requirements Traceability Matrix ... 29
4 Implementatie... 30
4.1 CORBA initialisatie... 32
4.2 Overdracht van waarden ... 34
5 Testen van Custodian®... 36
6 Resultaten en Conclusies ... 37 6.1 Resultaten ... 37 6.2 Conclusie... 38 7 Aanbevelingen ... 39 7.1 Nokia-12i ... 39 7.2 Berichtprotocol... 39 7.3 Custodian®... 39 8 Persoonlijke ontwikkeling... 40 8.1 Competenties... 40 8.2 Vaardigheden ... 40
Inleiding
Vandaag de dag wordt het steeds belangrijker om werkzaamheden efficiënt uit te voeren. Een reden hiervoor is de wens een goede concurrentiepositie te behalen of behouden. Vooral op service kan veel bespaard worden. W aar vroeger een technicus nog op locatie machinerie moest onderhouden, is het nu wenselijk om dit op afstand te kunnen. ‘Enterprise Level Remote Assets Management’ is hierdoor een hot item.
Een voorbeeld: Océ levert wereldwijd printapparatuur aan allerlei soorten bedrijven. Hoe de kwaliteit van deze apparaten ook is, soms moeten er onderdelen vervangen worden, of is simpelweg de toner op. In een bedrijf met meerdere alternatieven is dit geen probleem, maar een klein bedrijf kan er behoorlijk last van hebben. Océ kan ervoor kiezen om een mogelijkheid tot op afstand service verlenen te implementeren. Hierdoor kunnen zij snel ingrijpen bij defecten, voorspellen wanneer nieuwe onderdelen geleverd moeten worden en klein onderhoud op afstand uitvoeren. Dit is zowel voor de klant als het bedrijf prettig.
ICT Embedded is niet achter gebleven bij deze trend en heeft voor het op afstand beheren een product ontwikkeld onder de naam Custodian®. Origineel is dit product ontwikkeld om rechtstreeks op een te beheren machine geïnstalleerd te worden. Dit is echter niet op alle apparatuur mogelijk. Een machine-to-machine (M2M) interface biedt hier uitkomst. In een voorgaand afstudeerproject is dan ook het Custodian product omgezet om op een Nokia-12i GSM module te werken. Daarnaast zijn er binnen ICT Embedded ook verscheidene afstudeerstages geweest, waarbij voortgebouwd is op het Custodian product. Zo is er bijvoorbeeld een track en trace toepassing voor vrachtwagens geïmplementeerd.
De originele uitvoering van Custodian® is in 2003 ontwikkeld volgens de toen gangbare technieken. De wens is er echter om te evalueren wat de huidige technieken zijn op de relevante gebieden en hoe deze in het Custodian® product toegepast kunnen worden. Op basis van research en prototyping zal een implementatie van een Custodian® product opgeleverd worden.
Tot dit doeleinde is een research document geschreven, waarin de belangrijkste onderdelen van Custodian genomen worden en voor elk onderdeel bekeken wordt welke technieken er beschikbaar zijn. Op basis van dit document kunnen beslissingen gemaakt worden over het implementeren van het Custodian product in een bepaalde situatie. Zo ook voor de situatie zoals deze bij ICT Embedded aanwezig was.
Op basis van de beslissingen uit het researchdocument is het systeem ontworpen. Tijdens het verloop van het project is het V-model gevolgd, waarvoor er in het kwaliteitssysteem van ICT Automatisering templates voor ontwerpdocumenten aanwezig waren. Tijdens het doorlopen van het traject zijn er eisen aan het systeem en de software opgesteld, is de systeemarchitectuur ontworpen en zijn testdocumenten opgesteld waaraan de implementatie achteraf werd onderworpen.
In het eerste hoofdstuk van dit document zal beschreven worden in welke context het project staat. Hier wordt ook de organisatie van het afstudeerbedrijf besproken en komt ook de divisie en plaats van de opdracht aan bod. In het tweede hoofdstuk wordt gesproken over de probleemstelling. Hierbij komen voornamelijk de doelstellingen van het project naar voren. Daarna zal in hoofdstuk drie het research document en de aanpak volgens het V-model beschreven worden. Uit elke deliverable dat hierbij opgeleverd wordt zullen de
belangrijke zaken uiteengezet worden. In hoofdstuk vier worden de belangrijke componenten uit de
implementatie beschreven. Hierbij zullen belangrijke delen van de code getoond worden. Het hierop volgende hoofdstuk, hoofdstuk vijf, zal de resultaten en conclusies van het afstudeerproject bespreken. Tot slot worden er in hoofdstuk zes nog aanbevelingen gedaan. Hierbij ook een discussie van de problemen die tijdens het project naar boven zijn gekomen.
1 Afstudeerorganisatie
1.1 ICT Automatisering N.V.
In 1978 werd het bedrijf ICT opgericht. Dit staat voor Industriële Computer Toepassingen, wat het werkgebied van ICT oorspronkelijk beschreef: embedded software oplossingen. De twee oprichters, Gerard Sanderink en Hans Quellhorst hadden op dat moment al samen gewerkt bij Philips Medical Systems, waar ze beiden gedetacheerd waren. In 1991 telde ICT 400 werknemers. Op dat punt wilde Quellhorst een deel van het bedrijf verkopen. Sanderink was het hier niet mee eens en besloot te breken met zijn zakenpartner.1
Maar ook zonder Sanderink is ICT alleen maar gegroeid. In de loop der jaren heeft ICT zich ontpopt tot de marktleider in embedded software. Mede vanwege het succes zijn de aandelen van ICT Automatisering N.V. sinds 26 juni 1997 op de Eurolist van Euronext Amsterdam genoteerd. Vandaag de dag telt ICT ongeveer 1000 werknemers in Nederland. Daarnaast heeft ICT ook vestigingen in Polen en Duitsland.
ICT Automatisering bestaat uit drie divisies: ICT Solutions (proces automatisering), ICT Embedded en ICT NoviQ (training, consultancy en implementatie van processen). Deze drie divisies tellen samen ongeveer 1000 medewerkers. Naast deze divisies heeft ICT Automatisering N.V. ook nog een aantal dochterondernemingen en samenwerkingsverbanden met andere bedrijven, zoals te zien is in figuur 1. De hoofddivisies van ICT hebben vestigingen in Barendrecht, Eindhoven, Deventer, Groningen, München (Duitsland) en Gdansk (Polen).
Figuur 1 - Divisies & dochterondernemingen van ICT
Om de kwaliteit van een project te waarborgen werkt ICT op CMM level 3, zoals in 1999 door Teraquest (VS) beoordeeld is. Om de professionals te ondersteunen bij het opstellen van documenten op dit kwaliteitsniveau maakt men gebruik van het Q-systeem, een database die voor elke medewerker van ICT beschikbaar is. In dit systeem zijn templates te vinden voor alle standaard gebruikte documenten binnen ICT. Daarnaast is voor elk template een korte beschrijving beschikbaar over hoe deze dient te worden ingevuld.
1
1.2 ICT Embedded B.V.
ICT Embedded B.V. is de divisie van het bedrijf waarin het project plaats vindt. Dit is tevens de divisie waarmee ICT marktleider op het gebied van embedded applicaties is geworden. Er zijn ook in deze divisie verscheidene branches te onderscheiden, zoals in onderstaande tabel te zien is.
Branche Product voorbeelden
Communications & Multimedia
- Applicaties voor mobiele telefoons. - Set-top boxes t.b.v. Digitale TV. Healthcare - DICOM2 Validation Toolkit
- MRI / X-ray / CT - scanners Manufacturing - Aansturing productielijnen
- ASML Twinscan (t.b.v chip productie).
Traffic & Automotive - Navigatie- en entertainment systemen in de Volkswagen Phaeton. - High end infotainment systeem in de Bentley Continental GT.
Tabel 1 - Branches ICT Embedded B.V.
De grootste vestiging van ICT Embedded B.V. en tevens de vestiging waar de afstudeeropdracht plaats vond is op het Science Park te Son, dicht bij Eindhoven. Veel grote klanten van ICT hebben zich in deze omgeving gevestigd, waaronder ASML en Philips. Andere grote klanten zijn NXP, Nokia, Océ, Siemens, Bosch en TomTom.
In figuur 2 is te zien waar de technisch begeleider, de procesbegeleider en de student in de organisatie van ICT Embedded B.V. staan. Louis van Gool is normaliter werkzaam als consultant binnen de divisie NoviQ, maar is in de rol van technische begeleider een professional in ICT Embedded B.V.
Figuur 2 - Organigram ICT Embedded B.V.
2
2 Probleemanalyse
2.1 Context
Custodian® is een Enterprise Level Remote Assets Management systeem. De taak hiervan is om een fabrikant in staat te stellen zijn producten op afstand te analyseren, besturen en updaten. De noodzaak om dit ter plaatse te laten doen, wordt geringer, wat zowel voor leverancier als klant financieel aantrekkelijk is. Custodian® is een bekend begrip binnen ICT, het project bestaat namelijk al sinds 2003. Het framework is in eerste instantie ontworpen voor directe implementatie op een machine. In een afstudeeropdracht voorafgaand aan deze is de overstap naar een M2M module gemaakt. Hier is op voortgebouwd in andere
afstudeerprojecten. Een voorbeeld: Custodian® is in het verleden succesvol toegepast bij Stork Digital Imaging. Hier is het toegepast voor preventief onderhoud van hun digitale printapparatuur. Het gebruik van Custodian heeft er hier voor gezorgd dat er minder servicebezoeken nodig waren, deze korter duurden en ongeplande machinestilstand werd voorkomen. Ook kon voorraadbeheer op basis van actuele
consumptiegegevens plaatsvinden.
Het originele Custodian® bestaat uit twee subsystemen, Custodian® Embedded, dat wordt meegeleverd op iedere machine die door de leverancier wordt uitgeleverd en een Custodian® Back Office, die binnen de organisatie van de leverancier wordt opgezet. Deze subsystemen communiceren met elkaar via het internet. Het Custodian® project is na de initiatie in 2003 continu in beweging geweest. Zo is het Embedded
subsysteem later geïmplementeerd op de Nokia-12i, zoals in figuur 3 te zien is. Deze module maakt het mogelijk om het systeem via GSM netwerken te laten communiceren.
Figuur 3 - Custodian context
2.2 Probleembeschrijving
Het probleem gedurende dit afstudeerproject is tweeledig. Het eerste is de huidige instabiliteit van de Custodian server. Het originele systeem is niet ontworpen met het oog op latere aanpassingen. Deze zijn wel gedaan, waardoor er een zodanig complexe implementatie is ontstaan dat deze voor ontwikkelaars moeilijk te overzien en stabiel te maken is. Besloten is dan ook een compleet nieuwe implementatie van Custodian® te starten, waarbij het oude design geraadpleegd zal worden om de visie op het Custodian® systeem te bewaren. Ten tweede heeft de IT sinds het ontstaan van Custodian® niet stilgestaan. Het is niet ondenkelijk dat in de afgelopen vijf jaar nieuwe technieken de kop op hebben gestoken, die een nieuwe implementatie slimmer, sneller of veiliger kunnen maken. Dit moet dan ook onderzocht worden, zodat eventuele nieuwe designkeuzes meegenomen kunnen worden in het project.
2.3 Doelstelling
De opdracht van de afstudeerder is voornamelijk gericht op het onderzoek naar voorgenoemde nieuwe technieken voor de implementatie van Custodian®. Hierbij moet door middel van prototypen de werking en effectiviteit getest worden, zodat op basis van het onderzoek voor een eventueel nieuw design gekozen kan worden.
Op basis van dit design wordt daarna een ontwikkeltraject doorlopen. Dit ontwikkeltraject zal volgens het V-model plaatsvinden, zoals deze toegepast wordt binnen ICT. Hiervoor zijn faciliteiten in het eerder genoemde Q-systeem te vinden. Vanuit het research document wordt eerst een Software Requirements Document opgesteld, waaruit weer een Object-Oriented Architectural Design Document opgeleverd wordt. Als laatste, nog vóór de implementatie, zal het Test Design opgeleverd worden.
Het doel is om uiteindelijk een API op te leveren, waarvan ontwikkelaars gebruik kunnen maken om een Custodian® Back Office applicatie te implementeren. In het kort moet deze API een ontwikkelaar in standaardoplossingen voorzien voor het op afstand analyseren en besturen van een machine. Omdat de communicatie van de API ook getoond moet kunnen worden, zal hier een testapplicatie op gebouwd worden. Deze applicatie zal communiceren met een minimale implementatie van Custodian® Embedded op de Nokia-12i.
De op te leveren deliverables zijn dus: - Research Document
- Software Requirements Document
- Object-Oriented Architectural Design Document
- Implementatie API met Back Office en Embedded testapplicatie, incl. handleiding - Test Resultaten
- Afstudeerrapport
2.4 Randvoorwaarden
Om de opdracht succesvol af te ronden, is er beschikking tot een werkplek met alle benodigde ontwerp- en ontwikkelomgevingen. Vanuit het bedrijf zijn er twee begeleiders aangesteld. Louis van Gool treedt als technisch begeleider op en zal de op te leveren producten inhoudelijk beoordelen. Frank Fleuren neemt de rol van procesbegeleider op zich. Dit houdt in dat hij ervoor zorgt dat tijdens de stageperiode alle benodigde middelen ter beschikking gesteld worden en de kwaliteit van producten en het project gecontroleerd wordt. Tevens zal hij het afstudeerproces begeleiden.
3 Aanpak
3.1 Plan van Aanpak
De eerste stap in het project is het maken van een Plan van Aanpak (PvA). Hierin wordt voor het eerst uiteengezet wat de verschillende onderdelen van het project inhouden en hoe deze aangepakt gaan worden. De hoofdstukken uit dit document worden in de volgende paragrafen beschreven. Het document zelf is te vinden in de bijgevoegde documentmap.
3.1.1 Projectachtergrond
Net als bij dit afstudeerdocument is het ook bij het PvA belangrijk om het in de juiste context te zien. Daarom wordt in het eerste hoofdstuk van het PvA kort opnieuw ingegaan op ICT Embedded en de relatie met de opdracht.
Het belangrijkste onderdeel van dit hoofdstuk is echter de probleemstelling. Het doel hiervan was om heel specifiek te kunnen stellen wat de situatie was en hoe deze moest veranderen.
3.1.2 Projectbeschrijving
Dit deel van het PvA begint heel simpel met de feiten. W ie is er betrokken bij dit project en in wat voor rol? Het belangrijkste gedeelte van dit hoofdstuk zijn de resultaten welke hierin gedefinieerd worden. Deze vormen de basis voor wat er tijdens het project gedaan gaat worden.
De volgende resultaten zijn in deze paragraaf aangeduid. Te zien is dat deze verschillen met de doelstellingen uit paragraaf 2.3. Dit komt door het feit dat het PvA achteraf aangepast is op de situatie zoals deze later in de conclusie beschreven wordt.
- Document: Techniekanalyse t.b.v. Remote Monitoring en Control - Document: Requirements Engineering
- Document: Software Design & Coding
- Document: Handleiding t.b.v. Back Office API en het schrijven van Custodian software - Implementatie: Back Office Application Programming Interface (API) voor Custodian - Implementatie: Custodian Embedded
Bij de projectbeschrijving is ook aangegeven wat de verwachte risico’s zouden zijn. Met deze risico’s moet tijdens de projectplanning rekening gehouden worden, in verband met eventuele uitloop.
3.1.3 Projectfasering
In dit hoofdstuk is te lezen wanneer de verschillende delen opgeleverd zullen worden en tot welke fase van het project zij behoren. Het is de opzet voor de planning, welke onder de paragraaf beheersaspecten aan de orde komt. In dit hoofdstuk is ook op papier gezet dat belangrijke beslissingen over design en implementatie in overleg met de technisch begeleider plaatsvinden. Ook wordt aangegeven dat er elke week reguliere contacturen met de begeleiders zijn, waarbij het een en ander afgestemd en bijgestuurd kan worden.
3.1.4 Beheersaspecten
Twee van de belangrijkste onderdelen van het PvA worden in dit hoofdstuk besproken. Op basis van de informatie uit het hoofdstuk projectfasering wordt de planning gemaakt en de manier waarop kwaliteit in het project wordt gewaarborgd, beschreven.
De meest recente planning is in de conclusie te vinden. De planning in figuur 4 en 5 is het origineel. Door de eerder genoemde risico’s is deze tijdens het afstudeerproces aangepast. Uitlooptijd en optionele onderdelen vangen deze veranderingen op, zodat dit geen groot probleem vormt. Verdere informatie hierover is in hoofdstuk zes te vinden.
Figuur 4 - Originele projectplanning (deel 1/2)
Figuur 5 - Originele projectplanning (deel 2/2)
Naast de planning is in dit hoofdstuk ook aangegeven hoe de kwaliteit van het project bewaakt zal worden. Het eerder genoemde Q-systeem van ICT komt hier weer ter sprake. Verteld wordt dat de richtlijnen en document-templates die hierin aangeleverd worden voortaan toegepast zullen worden. Ook dit
afstudeerdocument is in de algemene ICT-vorm gegoten door een template toe te passen.
Ook komt de ISO9126 bij kwaliteit aan de orde. Voor het researchdocument dat geschreven moet worden, zal deze ISO kwaliteitsstandaard aangehouden worden. Hierover wordt in paragraaf 3.2, ‘Research’, meer verteld.
3.2 Research Document
Een van de belangrijkste, zo niet hét belangrijkste onderdeel van het project is de research naar nieuwe technieken. Er wordt in dit document bepaald wat de belangrijke onderdelen van het Custodian® project zijn. Aan de hand van ISO standaard 9126: Software Engineering – Product Quality en aan de hand van
prototyping (het implementeren van de technieken voor praktische tests) worden hierna de technieken beoordeeld. Zo kan per onderdeel bepaald worden wat de stand van IT op dat gebied is, wat mogelijk leidt tot innovatie van het Custodian® project. Aan de hand van de resultaten in dit document kan door klanten een keuze gemaakt worden voor de technieken die voor hun doeleinden geschikt zijn.
3.2.1 ISO 9126
De gebruikte standaard, ISO 9126, is oorspronkelijk bedoeld om de kwaliteit van software systemen te beoordelen. Het is opgedeeld in vier onderdelen, te noemen: kwaliteitsmodel, interne metriek, externe metriek en gebruikskwaliteit. In het kwaliteitsmodel wordt bepaald wat de kwaliteitskenmerken (zie onder) zijn, de andere onderdelen bouwen hierop voort vanuit verschillende perspectieven.
Betrouwbaarheid - Bedrijfszekerheid - Beschikbaarheid - Herstelbaarheid - Foutbestendigheid - Degradeerbaarheid Portabiliteit - Installeerbaarheid - Vervangbaarheid - Volgzaamheid - Aanpasbaarheid Onderhoudbaarheid - Analyseerbaarheid - Wijzigbaarheid - Stabiliteit - Testbaarheid - Beheerbaarheid - Herbruikbaarheid Bruikbaarheid - Begrijpbaarheid - Leerbaarheid - Instelbaarheid - Bedienbaarheid - Uitrustingsniveau Functionaliteit - Juistheid - Geschiktheid - Inschikkelijkheid - Beveiligbaarheid - Koppelbaarheid - Traceerbaarheid Efficiëntie - Tijdsbeslag - Middelenbeslag
Deze kenmerken zijn in attributen onderverdeeld. Aan de hand van deze attributen kunnen
systeemonderdelen op kwaliteit gecontroleerd worden. De systemen zijn in dit geval de te beoordelen technologieën.
Welke onderdelen van het Custodian® systeem bepaald zijn en aan welke attributen de bijbehorende technieken zijn onderworpen, is in de volgende paragraaf te lezen.
3.2.2 Systeemcomponenten
De drie belangrijkste onderdelen van het Custodian® systeem zijn, zoals in figuur 6 is weergegeven, de communicatie tussen Custodian Embedded en Custodian® Back Office, het berichtprotocol dat voor deze communicatie gebruikt wordt en de M2M communicatie. Voor elk van deze componenten is bepaald wat er op het moment aan techniek beschikbaar is, en welke attributen hiervoor belangrijk zijn.
Figuur 6 - Custodian systeemcomponenten
3.2.2.1 Testopstelling
De implementatie van Custodian® Embedded gebeurt op een Nokia-12i M2M module.
Deze module heeft de mogelijkheid om via GSM netwerken te communiceren tot maximaal 2.5G. Een testbord is bij deze module meegeleverd, waardoor het beschikt over een RS232 poort, I/O poorten en een SIM kaartadapter.
Hiernaast is er intern door ICT ook een Machine Interface Board ontwikkeld. Deze heeft analoge uitgangen, potmeters en switches om zo goed mogelijk een generieke machine te kunnen simuleren. Een machine op locatie wordt in dit document verder ‘asset’ genoemd.
3.2.2.2 Communicatie Back Office en Embedded
Dit onderdeel van het systeem gaat over de dataoverdracht tussen de Back Office applicatie en de Embedded software op de Nokia module. De tests die hierop gedaan zijn, nemen dan ook geen specifiek berichtprotocol in acht. Het gaat hier om simpele binaire dataoverdracht over TCP/IP (Uitgezonderd SMS). De beoordeelde technieken zijn in tabel 2 te vinden.
Type Beschrijving
SMS Communicatie protocol voor overdracht van korte berichten tussen twee mobiele apparaten.
CSD Dataoverdracht volgens inbelwijze van mobiele spraakoverdracht. HSCSD Sneller vorm van CSD door gebruik van meerdere kanalen. GPRS Pakketgestuurde vorm van dataoverdracht.
EDGE Snellere vorm van GPRS door dynamische foutcontrole en efficiëntere codering. UMTS Aanpassing op EDGE waarbij gebruik wordt gemaakt van codering gestuurde
communicatie voor snellere dataoverdracht.
Helaas kunnen met de beschikbare hardware niet alle vormen getest worden. Zo is EDGE in Nederland niet beschikbaar en is UMTS op de Nokia module niet te gebruiken. Deze laatste is namelijk een 3G techniek, terwijl de module tot maximaal 2.5G ondersteunt. Vanwege de aard van CSD en HSCSD is alleen deze laatste meegenomen in de tests. Voor de volledige beschrijving van de tests en attributen, zie het [Research
Document].
Data corruption prevention
Ofwel, hoe vaak komt een fout in de overdracht voor? Op basis van de overdrachtsgarantie van een technologie is het mogelijk dat een deel niet aan komt bij de ontvanger. Een betere preventie van data corruptie wordt hier gemeten als minder verlies van pakketten, en dus data.
SMS HSCSD GPRS
Verzonden 50 200 200
Aangekomen 38 198 200
Verlies 12 2 0
Wat meteen opvalt is de slechte overdracht van SMS. HSCSD en GPRS presteren vele malen beter op dit gebied. Het verschil is echter simpel uit te leggen. Zodra er een fout gemaakt wordt zal TCP bij HSCSD en GPRS ervoor zorgen dat de data opnieuw verzonden worden. Echter, bij HSCSD zijn wel fouten opgetreden. Transmission Rate
Hoe lang duurt het overzenden van data over internet in de praktijk? Dit is voor de verschillende technieken onderzocht worden door het doorsturen van een relatief groot bestand. SMS is van deze test uitgesloten. Het opdelen van een groter bestand en deze in aparte SMS berichten versturen is een erg dure aangelegenheid.
SMS HSCSD GPRS
Snelheid - 13,4kbps 29,8kbps
Beide protocollen halen hun maximale snelheden niet. Wel is in de tabel te zien dat GPRS een hogere overdrachtssnelheid haalt bij het verzenden van grotere bestanden (150000 bytes). Bij mobiliteit van de ontvanger zal de uiteindelijke snelheid nog lager liggen.
Response time
De verschillen in overdrachtssnelheden tussen de verschillende protocollen zijn bekend, maar hoe is dit voor één commando? Om dit te testen wordt de tijd gemeten die het duurt om antwoord te krijgen op een
verzonden pakket.
SMS (enkel) HSCSD GPRS
Tijd 4,3 sec 423 ms 173 ms
Eigenlijk zijn alle protocollen vrij langzaam vergeleken met een landlijn. SMS is voor real-time toepassing absoluut niet geschikt en zou dus alleen gebruikt kunnen worden in situaties waar bijvoorbeeld de draadloze verbinding weg valt. HSCSD stuurt zijn pakketten ongeveer drie keer langzamer over dan GPRS. Dit kan voor tijdgevoelige overdrachten teveel zijn.
Memory utilization
Bovenal blijft Custodian Embedded een embedded programma. Het geheugen op de hardware is vaak beperkt. Daarom is voor elk protocol getest worden hoe groot de implementatie in KB’s is. Dit is gedaan door voor de drie protocollen HSCSD, GPRS en SMS een programma te schrijven waarmee een bericht wordt verstuurd. De minimale implementatie die nodig is, is vertaald naar een programmagrootte.
SMS HSCSD GPRS
Regels code 11 17 17
Er zijn geen grote hoeveelheden code nodig voor de basisfunctionaliteit, maar er is duidelijk verschil tussen het gebruik van SMS en GPRS/HSCSD. Dit zal alleen bij hele krappe geheugenruimte iets uitmaken. Cost (niet ISO-9126)
De kosten van een protocol verschillen, afhankelijk van de kosten voor de provider. Deze kosten zullen uiteindelijk in rekening gebracht worden voor de eindgebruiker van Custodian. Dit ‘attribuut’ is niet gedefinieerd in de ISO-9126 standaard, maar is wel van belang voor deze partij. De kosten zijn een gemiddelde van meerdere providers. De volledige tabel is in Appendix B van het Research Document te vinden.
SMS HSCSD GPRS
Gemiddelde kosten per MB
€1,12 €0,07 €0,04
Wat meteen opvalt, is dat sms erg duur is, omdat de inhoud van een tekstbericht veel kleiner is dan wat er in een MB past. HSCSD wordt normaal per minuut berekend. De cijfers hierboven zijn dan ook berekend aan de hand van de maximaal te behalen snelheid. Dit is in het voordeel van HSCSD, aangezien deze lang niet altijd behaald kan worden. Toch is GPRS goedkoper, terwijl het een snellere overdracht biedt.
Geographic Availability (niet ISO-9126)
Niet ieder protocol is in ieder land te gebruiken. Zo is EDGE in Nederland niet beschikbaar. Het is belangrijk in de keuze van een protocol of deze ook daadwerkelijk gebruikt kan worden. Hiervoor is achterhaald in hoeveel landen een protocol beschikbaar is.
SMS HSCSD GPRS
Landen beschikbaar 213 213 84
Te zien is dat SMS en HSCSD bijna overal ter wereld vertegenwoordigd zijn door een lokale netwerkprovider. GPRS is niet in elk land beschikbaar. Het is aan te raden per implementatiegebied na te gaan of GPRS door een provider geleverd wordt alvorens hier een keuze te maken.
3.2.2.3 Connectie M2M
De gebruikte Nokia module biedt op het gebied van interfacing met een asset twee verschillende
mogelijkheden. Deze zijn in tabel 3 terug te vinden. De verschillende te beoordelen attributen worden onder deze tabel weergegeven. Per attribuut zijn prototyping tests uitgevoerd, om de resultaten voor deze opstelling te bepalen.
Type Beschrijving
Bit/Poort manipulatie
Het rechtstreeks per bit of per poort waarden schrijven.
Serieel Het achter elkaar oversturen van binaire waarden, waarbij RS232 in dit geval het protocol vormt. Bit manipulatie is hier de onderliggende techniek.
Tabel 3 - Beschikbare technologie voor M2M communicatie
Response Time
Afhankelijk van de functie en mogelijkheden van de asset is het mogelijk dat tijdsintensieve acties plaats moeten vinden. Bij deze acties is het zeer belangrijk dat een opdracht snel uitgevoerd kan worden. Om de snelheid van beide benaderingen te testen zal over beiden een actie of bericht gestuurd worden. De tijd van aankomen/uitvoeren zal hierbij dan dienen als maatstaaf voor de snelheid van de oplossing.
RS232 Direct Pin
Tijd Maximaal 16ms Direct
Voor het testen van beide technieken is gebruik gemaakt van het programma ‘Serial Port Monitor’, waarbij gebruik wordt gemaakt van timestamps om tot op een milliseconde nauwkeurig te controleren wat voor vertraging in de verbinding zit. Een waarde op een pin zetten is een actie die niet veel tijd van de processor
vraagt. Een signaal wordt op de poort gezet, een voltage dat vertaald kan worden naar een digitale ‘1’ of ‘0’. Dit is een directe actie, omdat het zo snel gaat als een klokcyclus toelaat (mits deze geen hogere prioriteit processen moet verwerken). RS232 maakt van deze technologie gebruik. Een te verzenden bericht wordt omgezet naar de digitale ‘1’ en ‘0’ uit de vorige paragraaf. Dit is door de vertaalslag van het protocol wel langzamer dan directe pincontrole.
Memory Utilization
Ook hier is het weer belangrijk het een embedded programma betreft, welke beperkte opslagruimte tot zijn beschikking heeft. Het aantal kb’s aan implementatie dat nodig is om een van beide aanpakken te gebruiken zal hierbij als meetstaaf dienen. Hiervoor wordt een geoptimaliseerde implementatie gebruikt, waarin alleen de benodigde functionaliteit aanwezig is.
RS232 Direct Pin
Regels code 17 10
Programmagrootte 1.428 bytes 1.225 bytes
De code die voor beide vormen geïmplementeerd is, schrijft bij allebei één enkel bericht weg. Geen van beide technologieën gebruikt hiervoor veel code of ruimte op de module.
Customisability
Het Custodian product kan voor veel verschillende toepassingen gebruikt worden. De asset waarmee gecommuniceerd gaat worden, verschilt vaak ook per project. Bij dit attribuut wordt dan ook gelet op of de technologie zich makkelijk aan laat passen, ook als de asset over tijd verandert.
Niet elke asset heeft de mogelijkheid tot RS232 interfacing. Dit maakt RS232 in sommige situaties niet bruikbaar. Bij machinerie die bijvoorbeeld alleen met signalen voor besturing werkt, zonder enige software, is de pin techniek wel te gebruiken, maar RS232 niet.
Aan de andere kant, is een seriële aansluiting als enige beschikbaar, dan zijn allebei de technieken te gebruiken.
Ease of implementation
Hoe makkelijk de oplossing te implementeren is, op zowel hardware- als softwareniveau, hangt van meerdere factoren af. Het gebrek aan een protocol kan bijvoorbeeld een probleem opleveren. Aan de andere kant kan een asset een RS232 aansluiting missen. Dit wordt bij dit attribuut afgewogen.
Zoals aangegeven, is het mogelijk om met de pin techniek met vrijwel alle assets te interfacen. Het nadeel hiervan is enkel dat om bijvoorbeeld met RS232 te communiceren er een eigen protocol geschreven zou moeten worden. Ook voor het versturen van tekst en grotere bestanden moet in ieder geval een minimale implementatie van een protocol geschreven worden.
En dit is waar RS232 juist excelleert. Het protocol wordt in de industrie veel gebruikt en is geschikt voor het overzenden van zowel korte als lange berichten. Gebruik maken van het bestaande RS232 protocol is een stuk gemakkelijker dan het implementeren van een eigen serieel protocol.
3.2.2.4 Berichtprotocol
Een simpele TCP/IP verbinding is niet flexibel of veilig genoeg voor een systeem als Custodian. Dit houdt in dat er een berichtenprotocol gebruikt zal worden. De industrie kent twee grote namen, SOAP en Common Object Request Broker Architecture (CORBA). In de Internet Communications Engine (ICE) is een relatief nieuwe speler op de markt gevonden. Deze zal ook meegenomen worden in de overweging.
Type Beschrijving
SOAP XML berichtprotocol volgens RPC patroon over HTTP of HTTPS. CORBA GIOP berichtprotocol voor objectcommunicatie over TCP/IP.
ICE Sterk op CORBA gebaseerd berichtprotocol, maar naar eigen zeggen minder complex en efficiënter.
Completeness of Description
In welke mate is het protocol gedocumenteerd? Het kan zijn dat voor de ontwikkelaar het berichtprotocol nieuw is. Zonder goede documentatie, met eventueel voorbeelden, is het lastig om kennis te maken met dit nieuwe protocol. Zeker voor korte projecten kan dit problemen opleveren.
SOAP (1998) en CORBA (1991) zijn beide protocollen die al een tijd op de markt aanwezig zijn. ICE (2003) heeft nog maar een relatief korte periode gehad om bekendheid en aanhang te verwerven. Hierdoor heb je als je gebruik maakt van deze laatste techniek minder voorbeelden en onderzoek tot je beschikking. SOAP en CORBA zijn beiden hierin ruim voorzien.
Ease of implementation
Nadat de ontwikkelaar daadwerkelijk kennis heeft van het te gebruiken protocol, is de complexiteit van implementatie ook nog van belang voor bijvoorbeeld de doorlooptijd van het project, of de complexiteit van het programma als geheel.
Om een SOAP aanvraag te implementeren moet de programmeur een bericht opstellen, hieraan argumenten meegeven en dan het bericht sturen. Hierna moet op een antwoord gewacht worden, hiervan de XML naar een opdracht vertaald worden en hiermee de data verwerkt worden.
CORBA is een stuk functioneler en staat dichter bij de programmeerstijl van bijvoorbeeld Java of C++. Het neemt de ontwikkelaar een hoop uit handen. Communicatie wordt vooraf gedefinieerd. Alle methoden worden gespecificeerd in een IDL file, waarna vanuit deze de nodige interfaces worden aangemaakt. Hierna is het een kwestie van het implementeren van deze interfaces. Deze procedure is een stuk simpeler dan die van SOAP, omdat alleen bepaald wordt wat er overgedragen wordt, niet hoe deze overdracht eruit moet zien. ZeroC, de ontwikkelaars van ICE, vonden CORBA te complex. Implementatie is voor ICE dan ook nog
simpeler dan dat het voor CORBA is. Voornamelijk de IDL specificatie is erg versimpeld. Het grootste voordeel hiervan is dat er veel minder attributen en parameters geïmplementeerd moeten worden.
Implementatie wordt significant eenvoudiger als de library al beschikbaar is. Voor een embedded M2M omgeving is dit vaak het geval. Zo ook op de Nokia 12i: CORBA zit in de standaard library geïntegreerd, wat de ontwikkeltijd verkleint.
Data Encryption/Access controllability
De data die overgestuurd wordt tussen de Embedded software en de Back Office kan gevoelige informatie bevatten. Bevat het berichtprotocol of de onderliggende transportprotocollen wel encryptie van data? In hoeverre is beveiliging aanwezig? Als er beveiliging aanwezig is, is het nog de vraag of deze bijvoorbeeld verschillende gebruikers toelaat. In welke mate is de beveiliging aan te passen of te manipuleren?
SOAP gebruikt HTTP, het toepassingslaag protocol uit het OSI-model als transportlaag protocol. Dit is gedaan om ervoor te zorgen dat SOAP makkelijk door firewalls heen kan. Onbedoeld gebruik van HTTP maakt het protocol niet veilig. Naast de gaten die HTTP al bevat, zal de implementatie van de laag boven op dit protocol ook de nodige gaten met zich mee brengen. Een beveiligde verbinding is wel op te zetten door gebruik te maken van het HTTPS protocol. Het beveiligingsprotocol HTTPS kan ook gebruikt worden voor het uitsluiten van bepaalde cliënten, om te zorgen dat niet iedereen bij alle soorten data kan. Hierbij wordt voor elke gebruiker apart een certificaat gemaakt, waarmee dus restricties aan toegang gelegd kunnen worden. De beveiliging in CORBA is op zo’n manier opgezet dat het zonder extra inzet voor de ontwikkelaar toch gebruikt wordt. Met extra inspanning krijg je ook extra beveiliging. Er zijn drie niveau’s te onderscheiden, die elkaar niet uitsluiten. Per deel van de software kan ook een ander niveau ingezet worden.
Soort Beschrijving
Onwetende beveiliging De applicatie laat beveiliging compleet aan de middleware over.
Controlerende beveiliging De applicatie vertelt de middleware wat er aan beveiliging gedaan moet worden, maar laat het uitvoeren hiervan aan de middleware over.
Uitvoerende beveiliging De applicatie controleert en voert zelf de richtlijnen van beveiliging uit.
Buiten dit deelt CORBA het programma, afhankelijk van het gebruikte niveau de beveiliging, ook nog eens in twee lagen op. De ene laag voorziet in de algemene beveiliging. De andere laag leent zich als een interface voor programma’s die gebruik maken van controlerende of uitvoerende beveiliging. Hierdoor kan de
onderliggende laag continu veranderen zonder dat de ontwikkelaar er aanpassingen op moet maken. Het is hierbij ook nog eens mogelijk om verschillende beveiligingsniveau’s aan gebruikers toe te wijzen.
CORBA heeft dus zijn eigen beveiliging. In het verleden bestond het probleem dat implementaties meerdere, willekeurige poorten gebruikten. Tegenwoordig maakt CORBA ook gebruik van Transport Layer Security (TSL). Hierdoor is het mogelijk dat er een unieke poort gebruikt kan worden. Dit zorgt ervoor dat niet alleen de specifieke verbinding, maar ook de netwerken veilig blijven. Toch is het bij CORBA lastiger dan bij SOAP om te netwerken met firewalls, zeker voor grote bedrijfsnetwerken.
ICE is in ontwerp hetzelfde als CORBA, maar heeft een groot verschil op wat het biedt. In plaats van gebruik met TSL te ondersteunen, wordt hier een implementatie al meteen voor geleverd. Het is voor de ontwikkelaar dan makkelijker om veilige applicaties te maken. Ook wordt het probleem met firewalls van CORBA omzeild doordat ZeroC een eigen veilige oplossing voor firewalls heeft.
Resource Utilization
Het is niet bevorderlijk voor de software als het opstellen of verwerken van een bericht teveel
systeemresources in beslag neemt. Ook wordt vaak gewerkt met een minimale opslagcapaciteit. Ook hier is dus de grootte van de implementatie van belang.
Onder de alinea ‘Ease of Implementation’ is al genoemd dat SOAP tegenover CORBA/ICE een uitgebreidere implementatie vergt. Dit is terug te zien in de implementatie van SOAP, die meer ruimte in gebruik neemt dan zijn tegenhangers. Toch wordt deze niet te groot voor het gebruik in onze embedded omgeving. Wat wel een rol speelt is de veel lagere snelheid van SOAP door het gebruik van message parsing en serialisatie. Zeker voor kleinere berichten is SOAP vaak tien keer langzamer dan zijn tegenhangers CORBA en ICE. De overdracht van binaire berichten van deze laatste twee werkt sneller dan web services.
3.2.3 Keuze
Aan de hand van dit document is in samenwerking met de technisch begeleider een keuze gemaakt voor de implementatie. Besloten is om een ontwerp te maken met de technieken CORBA, RS232 en GPRS.
CORBA zal gebruikt worden omdat de J2ME library van de Nokia module hier ondersteuning voor heeft en hier ook gebruik van maakt voor de eigen instellingen. Ook is dit protocol kleiner om te implementeren en
daarnaast redelijk goed gedocumenteerd. SOAP wordt standaard niet ondersteund. Hiervoor zou bijvoorbeeld een eigen cliënt/server structuur geschreven moeten worden. ICE is te kleinschalig om genoeg informatie te vinden over het gebruik.
RS232 is aanwezig op zowel het Machine Interface Board als het Nokia testbord. Aangezien alle waarden van de MIB hierover uit- en ingelezen kunnen worden is het tijdsverkwisting om een eigen communicatieprotocol te schrijven, gebaseerd op bitmanipulatie.
GPRS blijkt naast de goede beschikbaarheid in westerse landen ook nog eens relatief goedkoop en snel te zijn. De constante verbinding via TCP/IP zorgt ervoor dat het implementeren van een internet connectie de programmeur vertrouwd is.
3.3 Software Requirements Document
In dit document worden de eisen aan het Custodian® systeem scherp gesteld. Het is de eerste stap in het V-model en een opzet voor de hierop volgende stap, het Architectuur Design Document. Vanwege de technische aard van het project en de verscheidenheid aan nationaliteiten binnen ICT Embedded, is dit document in het engels geschreven, zodat het voor iedereen die in de toekomst nog aan het Custodian® project zal werken, leesbaar is.
3.3.1 Algemeen
Het doel van dit document is het zo goed mogelijk weergeven van de eisen aan het Custodian® systeem vanuit het oogpunt van de klant. Omdat er op het moment geen externe afnemer van Custodian® is, fungeert de technisch begeleider hier als klant. Door middel van reviews met hem en de voormalige lead-designer van Custodian®, Marco Peters, zijn de eisen tot stand gekomen.
Bij het verder uitbreiden en scherpstellen van deze eisen is er gebruik gemaakt van een aantal oude eisen, gedocumenteerd in 2003. Deze boden extra perspectief op het systeem, zoals de visie van ICT Embedded hierop in die tijd. Ook waren de eisen makkelijker op te stellen doordat er bij het maken van het research document al gebruik was gemaakt van prototyping. Hierbij is veelvuldig gebruik gemaakt van de Nokia-12i. Vastgesteld is dat het systeem met behulp van het Java framework ontwikkeld moet worden. De Nokia-12i ondersteunt een geminimaliseerde versie van het J2ME framework, waardoor het Embedded subsysteem in deze taal ontwikkeld moet worden. De server is hierdoor ook in Java geïmplementeerd, zodat gebruik gemaakt kan worden van dezelfde ontwikkelomgeving. Deze omgeving is de gratis ontwikkelomgeving Eclipse.
3.3.2 Functional Requirements
Voor de volledige lijst van eisen raadpleegt u het Software Requirements Document [ICT.CUST.002]. Een paar belangrijke beslissen met betrekking tot het systeem worden hier uitgelicht.
“REQ1.2 The Back Office can identify an Embedded module as allowed to connect.”
Niet alle systemen die een connectie naar de Back Office leggen hebben daar een geldige reden toe. Zo zijn er Embedded modules van andere bedrijven welke naar een eigen server moeten verbinden, maar ook kwaadwillige gebruikers, die de eventuele zwakheden van het protocol willen misbruiken. Verder is de eis dat externe gebruikers die geen toegang mogen hebben, de toegang ontzegd wordt.
“REQ2.2 The Back Office API can communicate with all connected modules at once.”
Een broadcast systeem voorziet in de mogelijkheid om alle Embedded modules tegelijk te waarschuwen over een verandering in de server. Hierbij is bijvoorbeeld te denken aan een herstart van de server.
“REQ8 The Back Office can continuously receive data from connected Embedded modules.” Het is erg belangrijk dat data niet verloren gaat. Vooraf is niet duidelijk wat het belang is van de
binnenkomende data. Daarom moet ervoor gezorgd worden dat alle door de Embedded modules verzonden data ook daadwerkelijk aankomt.
“REQ9.3 Users can have different levels of access.”
Afhankelijk van het bedrijf waar de Back Office gebruikt wordt, kan het voorkomen dat verschillende medewerkers, verschillende rechten hebben. Het is de bedoeling dat het systeem meerdere vooraf te definiëren niveaus van toegang toelaat.
3.3.3 Non-functional Requirements
In dit deel van het document worden de niet-functionele eisen voor softwarekwaliteit gedefinieerd. De eisen, die ook wel kwaliteitsattributen worden genoemd, zijn gespecificeerd in het eerder genoemde ISO 9126 model. Te lezen is bijvoorbeeld dat de implementatie volledig in Java gebeurt en waarom. Ook worden extra kwaliteitseisen gesteld in verband met het opleveren van een API en de veiligheid van de verbinding.
3.4 Architectural Design Document
Het ADD beschrijft het object-georiënteerde design van het Custodian® systeem vanuit een aantal
perspectieven. Het is bedoeld voor de participanten van het Custodian® project. Omdat het document met 27 pagina’s vrij uitgebreid is, zullen hier de belangrijkste onderdelen samengevat worden, te beginnen met de algemene uitleg over de opzet van het document en de te gebruiken standaarden. Alle diagrammen zijn ontworpen in StarUML, een gratis open-source UML tool.
3.4.1 Standaarden
Dit document is geschreven volgens de “4+1 View Model of Architecture” methode (zie [UML]). Hierbij wordt gebruik gemaakt van een vijftal perspectieven op de architectuur van het systeem. Deze zijn in figuur 7 weergegeven. 1 Design View 2 Implementation View 3 Process View 4 Deployment View +1
Use Case View
Figuur 7- 4+1 View Model of Architecture
Aan de hand van deze views wordt in de komende paragrafen de architectuur uit doeken gedaan. Daarbij zal ook uitleg gegeven worden over wat de views inhouden en op welke manier ze voor het ADD gebruikt zijn. Hierbij is de ‘Implementation View’ buiten beschouwing gelaten, omdat deze niet geschikt bleek te zijn voor dit systeem.
Bij het ontwerp van dit systeem wordt ook rekening gehouden met bepaalde codeerstandaarden. Deze zijn gedocumenteerd in de Java Coding Standard, een document dat beschikbaar is in het ICT Q-systeem. In dit document worden de conventies voor naamgeving, commentaarblokken en opmaak van de code beschreven.
3.4.2 Use Case View
Het Use Case perspectief toont de gewenste werking van het systeem. De actoren en hun acties/reacties worden hierin gedefinieerd. De diagrammen kunnen, omdat ze in begrijpelijke taal worden beschreven, gebruikt worden om met zowel de klant als ontwikkelaars te overleggen. De opzet van deze diagrammen is in dit document op verzoek van de technisch begeleider in de vorm van sequence diagrammen. Deze zijn voor het dynamische karakter van de use cases duidelijker.
Niet alle use cases zijn interessant genoeg om in dit afstudeerdocument opnieuw te tonen. In figuur 8 is te zien welke use cases in het SRD zijn beschreven. Hierbij is goed te zien welke actoren er aanwezig zijn. Wat meteen opvalt, zelfs in deze ene afbeelding, is dat de communicatie tussen de user van de API (de Back Office software) en de Embedded Module het meest uitgebreid is.
Figuur 8 - Use Case Survey Diagram
Een van de interessantere use cases is het ontwerp voor hoe een connectie opgezet wordt. De Back Office maakt voor elke aangesloten cliënt een object aan, een referentie waarop methoden aangeroepen kunnen worden. Deze wordt in een lijst gezet, aan de hand waarvan een unieke module benaderd kan worden, of alle modules tegelijk. Het is niet mogelijk voor een module om verbinding te maken zonder authenticatie. Naast de beveiligde SSL verbinding moet namelijk ook aangegeven worden of de module bijvoorbeeld wel bij het betreffende bedrijf hoort. Naam en beveiligingscode zullen deze daarom identificeren. Het sequence diagram hiervoor is te zien in figuur 9.
Embedded Back Office
1 : Connects
2 : Request authentication
3 : Authenticate
4 : Make client object
In verband met het aanmaken van een cliënt object bij een binnenkomende verbinding is het ook interessant hoe een connectie verbroken wordt. Uit het SRD is bekend dat dit van beide kanten moet kunnen gebeuren. De referentie naar de aangesloten cliënt wordt in beide gevallen verwijderd, of nou de cliënt of de server de verbinding verbreekt. Dit leidt tot de sequence diagrammen in figuur 10 en 11.
Embedded Back Office
1 : Disconnects
2 : Destroy client object
Figuur 10 – ‘Close Connection’ Use Case Diagram 1
Embedded Back Office
1 : Disconnects
2 : Destroy client object
Figuur 11 – ‘Close Connection’ Use Case Diagram 2
Het op afstand overnemen van de controle over een asset kan niet zomaar en door iedereen gebeuren. Een gebruiker moet al ingelogd zijn en voldoende rechten te hebben om de controle over te nemen. Ook al heeft hij deze rechten, dan nog moet een operator bij de asset toestemming geven voor de overname, dit om ongelukken te voorkomen. De werking hiervan is in figuur 12 te zien.
User Embedded
1 : Requests remote control
2 : Responds
3 : Initiates remote control
Figuur 12 – ‘Request control'
In het geval van een connectieprobleem zal er geen antwoord op de aanvraag komen. Voor de continue werking van het systeem is het van belang dat deze na een tijd aanneemt dat de aanvraag verkeerd is gegaan. Mocht er nog een antwoord op de aanvraag komen, dan zal deze genegeerd worden.
3.4.3 Design View
Het design perspectief laat zien welke objecten in het systeem belangrijk zijn. Deze zullen verantwoordelijk zijn voor het gedrag van de software. Het idee is om de functionele eisen om te zetten naar deze objecten. Het context model (figuur 13) laat zien dat het systeem, wanneer het opgeleverd wordt, maar één interface bevat: een interface met Custodian® Embedded. Over deze interface ‘IEmbedded’ wordt in het [ADD] gesteld dat deze interface TCP/IP gebruikt en hierbij CORBA, zoals duidelijk is geworden in het research document.
Figuur 13 – Custodian context model
In het Custodian® systeem uit figuur 13 komen meerdere sub-onderdelen voor, geïmplementeerd in packages. Deze packages zijn weergegeven in figuur 14, het static software diagram. Ook de onderlinge relatie tussen deze onderdelen is hierin weergegeven.
Figuur 14 – Static Software Diagram
De functionaliteit van de verschillende onderdelen is als volgt:
Subsystem Responsibility
User Verzorgt toegangscontrole en database beheer.
Acquisition Verzorgt alle binnenkomende datawaarden. Control Verzorgt bestuur op afstand van de asset.
Settings Zorgt voor de instellingen van zowel de asset als de Back Office. Connections Verzorgt connecties met Embedded modules.
In onderdeel 3.4.2 ‘Use Case View’ is al gesproken over het dynamische karakter van het systeem. Deze wordt in de design view verder uitgewerkt. Het voorbeeld, Figuur 15, toont wat er van de software verwacht wordt als er een waarde van de Embedded Module naar de Back Office wordt gestuurd. De user in dit geval is Custodian® Back Office. Deze heeft een bestaande verbinding met een Embedded module. De RandomHandler is of ‘Acquisition’, of ‘Logging’, of ‘Control’, maar voor dit voorbeeld maakt het niet uit.
Figuur 15 - Verwacht gedrag van communicatie
Als de Back Office een waarde naar de Embedded module stuurt zal het via het cliëntobject in de ConnectionHandler doorgestuurd worden naar de Embedded module. Daarna krijgt deze mogelijk een antwoord. Dit antwoord wordt geïnterpreteerd, de waarde hieruit opgeslagen en deze waarde krijgt een timestamp. Daarna wordt deze beschikbaar gesteld aan de Back Office software. Er wordt gebruik gemaakt van een queue, om blokkeringen te voorkomen en een constante stroom van data toe te staan.
3.4.4 Process View
Het proces perspectief is gericht op het voorkomen van het botsen van processen. Het zorgt ervoor dat duidelijk is welke verschillende processen of threads er aanwezig zijn en waar. Ook wordt hier duidelijk wat voor berichten deze versturen. Figuur 16 toont de processen en de berichten die deze aan elkaar doorgeven.
3.4.5 Deployment View
Het stationering perspectief is bedoeld om te tonen hoe de verdeling van de software op de hardware is. Voor het Custodian® systeem geldt dat er per Back Office meerdere Embedded modules mogelijk kunnen
verbinden. Ongeacht het aantal, communiceren de onderdelen altijd via TCP/IP, zoals in figuur 17 te zien is. Embedded software is alleen aanwezig op de Nokia-12i. De software op de verschillende assets is geen onderdeel van het Custodian® systeem. In het huidige project is de Back Office tevens op één server aanwezig.
Back Office TCP/IP Embedded
Figuur 17 – Custodian Deployment diagram
3.4.6 Software architectural construction principles
Om te voorkomen dat er op een project met meerdere ontwikkelaars verschillende oplossingen voor hetzelfde probleem bedacht worden, zijn er ‘construction principles’. Deze zijn in feite, met maar één ontwikkelaar voor dit project, niet verplicht, maar toch handig voor de verantwoording van bepaalde keuzes.
Zo wordt in dit hoofdstuk van het ADD aangegeven dat de reactie op een fout in het systeem netjes
afgehandeld moet worden om de stabiliteit van het systeem te kunnen waarborgen. Ook zullen om deze reden bepaalde processen blokkeren zodra ze op een antwoord moeten wachten. W ordt dit niet gedaan, dan kan het voorkomen dat informatie corrupt raakt, of het systeem vastloopt.
Om de beveiliging van het systeem te verhogen worden alle acties opgeslagen in een logbestand. Hierin kan nagegaan worden wie welke acties hebben uitgevoerd. Ook is met het oog op de beveiliging bepaald dat CORBA gebruikt wordt, waarbij SSL ervoor zal zorgen dat niemand zonder rechten verbinding kan maken.
3.4.7 Requirements Traceability Matrix
Om ervoor te zorgen dat alles wat in het [SRD] geëist wordt ook daadwerkelijk ontworpen is, bevat het [ADD] een Requirements Traceability Matrix in Appendix A. Deze laat zien dat met het design alle eisen zijn ingevuld. Elke eis wordt op de volgende manier aan het ontwerp gebonden:
Requirement Software Design section
4 Implementatie
In dit hoofdstuk worden de belangrijke onderdelen uit de implementatie van het ontworpen Custodian®
systeem besproken. Dit gebeurt voor zowel de Back Office als de Embedded software. De Embedded software is een minimale implementatie, gebruikt om de functionaliteit van de Back Office te testen. Van beide
onderdelen wordt ten eerste het klassendiagram weergegeven. Hierin zijn de relaties tussen de verschillende klassen te zien. Daarna zullen belangrijke patronen en oplossing besproken worden.
In het klassendiagram in figuur 18 is goed te zien dat de klasse ‘Main’ de start van het programma is.
Deze erft over van het Midlet datatype. Alle imlets die op de 12i module geprogrammeerd worden vereisen dit. De verschillende stadia van de imlet, startApp(), pauseApp() en destroyApp(), moeten hierdoor geforceerd geïmplementeerd worden. De CORBA aanroepen naar de Back Office worden in deze klasse gedaan. ‘Setting’ is een klasse die specifiek gemaakt is om netjes een waarde op te slaan. ‘Attributes’ is dan ook de enige die hier gebruik van maakt, om de instellingen voor de server en de tijdelijke controle autorisatie op te slaan. De ‘EmbeddedImpl’ klasse is waar alle CORBA aanroepen geïmplementeerd worden. Deze roept in een aantal gevallen ook ‘Attributes’ aan, om waarden in te stellen. In de meeste gevallen handelt deze echter zelf de methode af.
Figuur 19 is het klassendiagram van de Back Office. ‘CORBAService’ is de eerste klasse die aangeroepen wordt in het programma, aangezien deze de CORBAserver tot stand brengt waarover aanroepen gedaan kunnen worden. Mocht hier een aanroep op gedaan worden dan is de implementatie hiervan in
‘BackOfficeImpl’ te vinden. Veelal roept deze een methode in ‘W atchdog’ aan. Dit gebeurt omdat er gebruik gemaakt wordt van het Observer patroon. W aarom dit van invloed is wordt later in dit hoofdstuk beschreven. Zodra er in de watchdog een verandering plaatsvindt geeft hij dit door aan al zijn Observers. In deze implementatie is dat alleen ‘Queue’. Deze laatste is geïmplementeerd als een thread en zorgt ervoor dat er geen waardes verloren gaan. ‘Queue’ wordt op zijn beurt weer geobserveerd door ‘Acquisition’, welke de gebruiker voorziet van eerder genoemde waardes. Dit kan zowel per bron als per enkele waarde gebeuren. Deze waardes worden gerepresenteerd door de klasse ‘Value’, waarin het type, de bron, de waarde en de tijd van ontvangst wordt bijgehouden.
De ‘Control’ klasse verzorgt de communicatie naar de Embedded modules. Hiermee wordt in eerste instantie nagegaan of er wel controle uitgeoefend mag worden over de Embedded module die gespecificeerd wordt. Hierna is het mogelijk om commando’s te versturen. Alle acties die gedaan worden binnen het systeem kunnen met ‘Logger’ (voor de Back Office) en ‘EmbLogger’ (voor de Embedded module) naar een bestaand geschreven worden. De opzet hiervan komt later in het hoofdstuk terug.
De klassen ‘User’ en ‘Database’ worden gebruikt om voor het systeem een object aan te maken, aan de hand waarvan bepaald wordt welke rechten een gebruiker heeft. Dit kan gebruikt worden om bijvoorbeeld een gebruiker uit te sluiten van controle over de Embedded module. Ook hier zal in het verloop van dit hoofdstuk meer beschreven worden, na figuur 19.
