User Driven Development

Transkript

1 [Dato] User Driven Development Udvikling af SITRANS FC410 SIMATIC TIA- Portal V13 demosoftware med User Driven Development Marc Nirari Kako brændstrup

2 Forfatter: Marc Nirari Kako Brændstrup Studie nummer: A11011 Titel: User Driven Development- Udvikling af SITRANS FC410 SIMATIC TIA-Portal V13 demosoftware med User Driven Development Fagområde: Automation Placering i uddannelsen: Professionsbachelorprojekt Uddannelsessted: Aarhus Maskinmesterskole Praktiksted: Siemens Industry Danmark Vejleder: Torben Egelund Rauff Adjunkt, Svagstrømsingeniør Dato for aflevering: 15. december 2014 Antal normal sider: (á 2400 tegn inkl. mellemrum) 35 (84205 tegn inkl. mellemrum) Antal bilag: 4 Underskrift: (Marc Nirari Kako Brændstrup) Side 1 af 48

3 Abstract The following report is a bachelor project made as the final project at Aarhus School of Marine and Technical engineering. The study investigates the potential of adopting the method User Driven Development in the development of Siemens Industry Denmark s demo software. Primarily the method is only used in the software industry. The sales engineers use the demo software in order to demonstrate the implementation of a product in an automated solution, whereas the customers use the demo software as inspiration to implement the product in their own production. The opposing user cases brings up a conflict of interests, which leads to the challenge of developing a satisfying demo software for both users. Furthermore, this led to the concept of adopting User Driven Development in order to secure and improve user satisfaction, and lower risks of developing a product that does not satisfy the users. Siemens Industry s demands, and the reason for their demands are investigated by qualitative interviews. Due to limitations it has not been prioritised to visit a customer and ask for their perspective, wherefore their demands and the reason for their demands, are found by the analysis of a fictitious customer case. The requested demands have come in to existence by the respondents vision of the human machine interface. It is by these visions the demands for functionality are created. The Minimum Viable Product is based on the users essential demands. The author has prioritised the most essential demands by investigating the users reasons for their demands. The most essential demands have led to the development of the Minimum Viable Product. To secure a successful development of the Minimum Viable Product the methodology struktureret programopbygning (structured program layout) is used. The reason for this methodology is to ensure further development with User Driven Development. This methodology is highly adaptable which compliments User Driven Development. Due to limitations it has not been prioritised to verify the method in practise. Therefore, a supposition was made in order to show how a potential mode of development could have looked like. The supposition is based on the fictitious customer case mentioned above. The supposition indicates further development of the Minimal Viable Product with User Driven Development. User Driven Development is a paradigm wherefore there is no established procedure. In order to implement the philosophy in the supposition the methodology SCRUM was used. Project managing tools from SCRUM were used in order to control the course of development. Side 2 af 48

4 The study only elucidates a suggestion for the line of procedure of adopting User Driven Development in the development of demo software at Siemens Industry. Consequently, the study does not corroborate the hypothesis that User Driven Development would improve customer satisfaction. However, the study is based on the precondition that User Driven Development improves customer satisfaction, wherefore the aim of the study was to disseminate the paradigm to the development of demo software within Siemens Industry. Additionally the dissemination of the paradigm from one industry to another, could lead to even further dissemination. Side 3 af 48

5 Indholdsfortegnelse Læsevejledning... 5 Begrebsafklaring... 5 Problemstilling... 6 Problemformulering... 7 Metode... 7 Afgrænsning... 9 Sitrans FC410 Coriolis virkemåde Funktionalitetskrav Siemens Industrys funktionalitetskrav til demosoftwaren Siemens Industrys hardwareplatform Programmets funktionalitet Kundernes funktionalitetskrav til demosoftwaren Kundescenarie Programmets funktionalitet Udvikling af Minimum Viable Product Minimums krav Baggrunden for minimumskravene Minimum viable product PLC programmet Baggrunden for PLC-programmet User Driven Development af demosoftwaren SCRUM Hvad er SCRUM Hvordan kan SCRUM understøtte UDD Udviklingsforløbet Opstart Sprint planning meeting Sprint backlog Sprintet Diskussion Konklusion Perspektivering Litteraturliste Side 4 af 48

6 Læsevejledning Alle hoved- og underafsnit begynder med en forklaring af formålet med det kommende afsnit. Besvarelsen af arbejdsspørgsmålene i problemformuleringen er opdelt i tre forskellige hovedafsnit. Hovedafsnittet funktionalitetskrav belyser besvarelsen af det første underspørgsmål i problemformuleringen. Hovedafsnittet Udvikling af Minimum Viable Product belyser besvarelsen af det andet underspørgsmål i problemformuleringen. Hovedafsnittet User Driven Development af demosoftwaren belyser besvarelsen af det tredje underspørgsmål i problemformuleringen. I rapporten benyttes der Vancouvermetoden til kildehenvisning. Begrebsafklaring Funktionalitetskrav: I rapporten benyttes dette begreb som et udtryk for de funktioner Siemens industry og kunden efterspørger fra demosoftwaren. Siemens solution partner: En Siemens solution partner er en selvstændig virksomhed, der er certificeret af Siemens til at udføre arbejdsopgaver for dem. MVP: I rapporten benyttes denne forkortelse for ordet Minimum Viable Product. Minimum Viable Product er et produkt, der opfylder minimumskravene, der er stillet til produktet. UDD: I rapporten benyttes denne forkortelse User Driven Development. User Driven Development er udviklingsfilosofi, hvor slutbrugeren af produktet inddrages i udviklingen af produktet. Side 5 af 48

7 Problemstilling I forbindelse med min afsluttende bachelorpraktik hos Siemens Industry, har jeg stiftet bekendtskab med Siemens brug af demosoftware i TIA-Portalen. Demosoftwaren er et tænkt eksempel på, hvordan Siemens produkter kan implementeres i en automationsløsning. Demosoftwaren består af en hardwareplatform samt softwaren, der specifikt er programmeret til denne. Dernæst indeholder demosoftwaren også dokumentation, der belyser softwarens virkemåde og idriftsættelsen af denne. Demosoftwaren udvikles med henblik på at vise, hvordan man kan implementere Siemens produkter i en automationsløsning, samt for at belyse forskellige funktioner ved enkelte produkter. Demosoftwaren benyttes både af kunder og af Siemens egne salgsingeniører. Kunderne bruger demosoftwaren som inspiration til, hvordan man kan implementere et produkt i en automationsløsning. Salgsingeniørerne bruger demosoftwaren til at demonstrere produktets funktioner og muligheder over for kunderne, så de får en større viden om produktet. Dette kan gøre det svært for Siemens som virksomhed, at udvikle demosoftware, der er tilfredsstillende for begge slutbrugere. Det skyldes, at det er nemmere for Siemens, at basere demosoftwaren på salgsingeniørernes krav frem for, at undersøge kundernes eventuelle krav til demosoftwaren. Desuden udvikles demosoftwaren normalt af Siemens headquarter i Tyskland, hvilket betyder at demosoftwaren ikke altid passer til det danske marked. Det kan betyde, at slutbrugerne ikke ser nogen særlig værdi i demosoftwaren, da det ikke er målrettet deres behov. Denne problematik har salgsafdelingen i Danmark oplevet hos demosoftwaren til produktet Sitrans FC410 Coriolis flowmåler. Da de oplever at kunderne, til trods for det nuværende demosoftware, stadig har svært ved, at idriftsætte Sitrans FC410 Coriolis, da den kommunikerer over Modbus RTU RS485. Denne problemstilling, kombineret med at Siemens headquarter ikke har taget højde for, at mange panelserier udgår pr. den 01/10/2014, har betydet, at det gamle demosoftware ikke længere er aktuelt for hverken kunder eller Siemens egne salgsingeniører, da dele af hardwareplatformen er udgået. Det har resulteret i, at salgsafdelingen i Danmark vil udarbejde et nyt demosoftware, der tilfredsstiller begge slutbrugere. Side 6 af 48

8 Problemformulering Problemformuleringen er formuleret på baggrund af problemstillingen: Hvordan kan man udvikle et demosoftware for produktet Sitrans FC410 Coriolis ved hjælp af User Driven Development? Ovenstående problemformulering vil blive besvaret ved hjælp af følgende underspørgsmål: Hvilke funktionalitetskrav har kunderne og Siemens Industry til demosoftwaren for Sitrans FC410 Coriolis? Hvordan kan man udarbejde et minimum viable product baseret på Siemens Industry og kundernes funktionalitetskrav? Hvordan kan minimum viable product fremadrettet videreudvikles? Metode Problemformuleringen vil blive belyst ved, at benytte den kvalitative metode. Dette vil ske vha. indsamling af kvalitativ empiri. Empirien vil blive indsamlet ved kvalitative interviews med den produktansvarlige ingeniør for Sitrans FC410 Coriolis. De kvalitative interviews vil blive udført som en blanding af strukturerede og ustrukturerede interviews med nogle faste hovedspørgsmål samt underspørgsmål i tilfælde af, at respondenten ikke selv berør emnet. Spørgsmålene vil være udformet som åbne spørgsmål med henblik på, at respondenten formulerer sine svar personligt for, at undgå manipulation. Ud fra den kvalitative empiri, vil jeg inducere mig frem til Siemens Industrys funktionalitetskrav til demosoftwaren. Grundet begrænsninger, har det ikke været muligt, at interviewe kunderne om deres funktionalitetskrav til demosoftwaren. Derfor vil jeg i opgaven selv påtage mig kunderollen. Det vil jeg gøre ved, at opfinde et kundescenarie, som mine faglige vurderinger vil tage udgangspunkt i. Jeg vurderer, at det ikke er problematisk for mig, at påtage mig kunderollen, da maskinmestre er en af målgrupperne for rapporten. Det vil have den konsekvens, at rapporten vil vinkle kundernes krav til demosoftwaren subjektivt. Det skyldes, at mine vurderinger til kravene for demosoftwaren indhold som maskinmester, ikke vil være repræsentativt for alle Siemens kunder. Desuden kan der argumenteres for, at Side 7 af 48

9 mine vurderinger kan være biased, da min praktikperiode hos Siemens, kan have givet mig et loyalitetsforhold til dem. Om ikke andet har det givet mig en større indsigt i netop deres produkter. Det betyder, at rapporten vil belyse funktionalitetskravene til demosoftwarens indhold på baggrund af den kvalitative empiri samt mine faglige vurderinger som maskinmester. Ifølge User Driven Development (UDD)-filosofien (1) påstræbes der, at udvikle et slutprodukt, der tilfredsstiller brugerne vha. brugerinddragelse. For at efterleve dette, er besvarelsen udarbejdet ud fra både Siemens Industrys og den fiktive kundes krav, idet det er dem, der kommer til at anvende det færdige produkt. Dog skal man være opmærksom på, at de to slutbruger har to forskellige user cases. Det betyder at der kan være en forskel i den funktionalitet, de vurderer, at demosoftwaren skal indeholde. Det skyldes, at Siemens Industry overvejende ser demosoftwaren som et salgsværktøj, mens kunderne formodentligt ser demosoftwaren som noget de kan låne til, at implementere produktet i deres egen produktion. Min faglige vurdering vil bygge på en redegørelse og en forståelse af Sitrans FC410 Coriolis virkemåde. Herefter vil jeg foretage en vurdering af hvilke funktioner, der kunne være relevante, set ud fra en maskinmesters perspektiv. Denne redegørelse af Sitrans FC410 Coriolis virkemåde vil blive udarbejdet på baggrund af produktets manual. Baggrunden for dette er, at flowmålerens virkemåde ikke kan antages for, at være almenkendt stof. Redegørelsen skal oplyse læseren om produktets virkemåde, så vedkommende kan stille sig kritisk over for mine faglige valg gennem rapporten. Under udarbejdelsen af demosoftwaren, vil jeg benytte UDD, der er en filosofi inden for softwareudvikling. Dette softwareudviklingsparadigme handler om, at inddrage brugeren i udviklingsforløbet løbende gennem hele projektet. (1) Derfor har jeg tænkt mig, at udvikle et Minimum Viable Product(MVP) på baggrund af de essentielle funktioner, slutbrugerne efterlyser i rapporten, samt med inspiration fra det gamle demosoftware. Baggrunden for at vælge UDD er for, at sikre, at udvikle et produkt, der tilfredsstiller begge slutbrugere. Derfor vurderer jeg, at UDD er den bedste metode, da det sikrer et minimalt ressourcespild. Det skyldes, at UDD har indbygget Lean, hvilket betyder, at enhver brug af ressourcer, der ikke resulterer i værdiskabelse for kunden, er et mål for elimination. Desuden vurderer jeg, at metoden vil belyse funktionalitetskravene til demosoftwarens indhold bedre, end hvis jeg udelukkende havde induceret mig frem til disse på baggrund af den kvalitative empiri. Dette skyldes, at det er lettere for respondenten, at forholde sig til et konkret produkt frem for en idé. Der kan argumenteres for, at jeg ikke kan påtage mig både kunde- og udviklerrollen objektivt, da jeg som udvikler har større indsigt i produktet, herunder dens funktion og virkemåde m.v., end den almindelige kunde. Desuden bliver udviklingsforløbet subjektivt, da jeg ikke er repræsentativ for Siemens Industrys kunder. Metoden kan også resultere i, at produktet bliver Side 8 af 48

10 for omfangsrigt og derved mister brugervenligheden. Dette kan skyldes, at slutbrugerne kan stille urealistiske krav til demosoftwaren. Det er derfor min pligt som udvikler, at undgå en sådan situation. I litteratursøgningen har det været meget udfordrende, at finde valid litteratur til belysning af UDD. Dog vurderes det, at valgte kilde stadig kan benyttes, da den udelukkende er brugt til inspiration i arbejdet med UDD. I rapporten er UDD hovedsageligt blevet anvendt som en udviklingsfilosofi, hvorfor SCRUM-metoden (2) er brugt til at understøtte UDD. Rapporten har taget udgangspunkt i den Schweiziske IT-professionelle Kayo Dittmars udlægning af Scrum-metoden, og det er ud fra hans definition af Scrum, at problemstillingen belyses. Til at vurdere hvilke informationer, der er vigtige at belyse angående funktionalitetskravene til demosoftwaren, benyttes bogen Håndbog i Struktureret Programudvikling (3). Formålet med at benytte denne kilde er, at den med sin metodik, vil være et redskab til lettere, at belyse funktionalitetskravene til demosoftwaren. Kilden er første gang trykt i 1988, men i rapporten anvendes et genoptryk fra Normalt vil kilder af en sådan dato ikke være valide, da udviklingen inden for dette felt, har flyttet sig meget i denne tidsperiode. Dog udgiver Nyt Teknisk Forlag fortsat kilden, og man må derfor antage, at indholdet løbende valideres. Det vurderes derfor, at kilden forsat kan anses for værende valid. Afgrænsning Der vil i denne rapport udelukkende blive taget udgangspunkt i Siemens egne produkter til, at belyse problemstillingen beskrevet i problemformuleringen. Derfor vil man ikke få belyst samtlige måder, at udarbejde demosoftwaret Sitrans FC410 Coriolis. Endvidere vil demosoftwaret blive udarbejdet i Siemens TIA-Portal, da paneler der kan køre Step 7 V 5.5 udfases. Rapporten vil derfor kun være anvendelig for de kundegrupper, der ønsker at implementere Sitrans FC410 Coriolis i en automationsløsning, der er baseret på TIA-Portalen. Jeg har i rapporten afgrænset mig fra kravene til hardwareplatformen selvom, at dette kunne være interessant set fra et kundeperspektiv. Det kunne være interessant, da ikke alle kunder har samme krav til hardwareplatformen, hvilket kan skyldes kundernes sikkerhedskrav. Jeg afgrænser mig fra dette emne på baggrund af, at det er Siemens Industry, der har udleveret hardwareplatformen til udviklingen af demosoftwaren. Derfor har jeg vurderet, at det er spild af mine ressourcer, at undersøge kravene til hardwareplatformen, da jeg ikke selv har mulighed for at præge denne del af projektet. Side 9 af 48

11 Jeg vil i rapporten udelukkende fokusere på, at undersøge selve softwarens indhold og hvordan den udvikles i TIA-Portalen. Derfor vil jeg afgrænse mig fra den del af demosoftwaren, der omhandler dokumentation. Det betyder, at rapporten kun vil undersøge demosoftwarens softwareperspektiv og ikke omhandle de to andre elementer: hardwareplatform og dokumentation. Jeg har valgt at afgrænse mig fra dokumentationen, da softwaren er dén del, kunden vil benytte mest, da man kun benytter dokumentationen til at idriftsætte projektet. Dette valg har jeg truffet på baggrund af en cost benefit analyse om, at der ikke er ressourcer til, at belyse begge elementer. Det skyldes, at jeg vurderer, at dokumentationsaspektet i demosoftwaren, kan være en opgave i sig selv. Desuden vurderer jeg også, at ved at fokusere på softwaren, tillader det mig, at gå mere i dybden med det og opnå større indsigt i emnet. Det kan betyde, at demosoftwaren kan være umulig, at idriftsætte for kunderne uden dokumentationen. Jeg vil i rapporten afgrænse mig fra alle resterende processer, der indgår i kundescenariet. Altså, vil det kun være de processer, der kortlægger funktionalitetskravene til PLC-program, der belyses. Det er et bevidst valg til trods for, at det anerkendes, at processen der leder op til dét punkt, hvor PLC-programmet kommer i fokus er interessant. Det kunne være interessant, da man vil få et indblik i, hvordan kunderne udvælger den nødvendige hardware. Det betyder, at rapporten ikke belyser, hvordan en eventuel udvælgelsesproces af hardware ser ud fra kundens perspektiv. Dette skyldes, at opgaven ikke lægger fokus på dette, da kundescenariet primært bruges til, at undersøge funktionalitetskravene til demosoftwaren fra kundevinklen i opgaven. Side 10 af 48

12 Sitrans FC410 Coriolis virkemåde Flowmålerens målinger er baseret på Coriolis lov om bevægelse, der betyder, at partikler der bevæger sig i et roterende og vibrerende system, vil modstå pålagte svingninger i overensstemmelse med deres masse og hastighed. Vibrationerne der er skabt i Coriolis flowmåleren, skabes af selve procesmediet der accelererer omkring de interne bøjninger i flowmåleren. Dette vil resultere i fordrejninger af målerørenes fase. For at kunne omsætte disse fordrejninger til måleværdier, er flowmåleren udstyret med en elektromagnetisk (svingspole). Denne svingspole er placeret på målerørene internt i flowmåleren, så den kan måle resonansfrekvensen, der skabes i rørene, når procesmediet strømmer igennem. Derudover er der placeret to symmetriske pickups på hver sin side af den elektromagnetiske (svingspole). Dette skyldes, at de skal give positionsdatasignaler for målerørenes ender til digital behandling. Figur 1: Coriolis princippet (4) Når procesmediet strømmer igennem målerørene, vil Coriolis kraft skabe en faseforskydning. Denne faseforskydning mellem de to pickups, er vist ved figur 1 og er proportionel med masseflowet. Figuren viser også, at frekvensen på disse pickups, er en direkte funktion af procesmediets densitet. Frekvensen og amplituden af den elektromagnetisk (svingspole) er reguleret for, at sikre stabile målinger fra de to pickups. Dette gøres ved, at måle procesmediets temperatur, så der kan foretages kompensation for procesmediets viskositet. (4) Side 11 af 48

13 Funktionalitetskrav Afsnittet vil belyse Siemens Industrys og kundernes funktionalitetskrav til demosoftwaren, så der skabes et overblik over disse. Kravene til demosoftwaren, der er nævnt i dette afsnit, skal bruges til, at udvikle et minimum viable product. Det betyder, at afsnittet vil give et overblik over hvilke funktioner, der efterspørges i demosoftwaren samt hvorfor disse efterspørges. Det kan bruges som et user story map kendt fra UDD. Afsnittet vil også belyse, hvilken hardwareplatform den produktansvarlige ingeniørs besvarelse tager udgangspunkt i. Siemens Industrys funktionalitetskrav til demosoftwaren vil som nævnt i metodeafsnittet, være inducerede ud fra den kvalitative empiri og tage udgangspunkt i Siemens Industrys hardwareplatform. Kundernes krav til demosoftwaren vil bygge på min faglige vurdering af hvilke funktioner, der kunne være relevante, set fra et maskinmesterperspektiv, med udgangspunkt i et kundescenarie. Kundescenariet er en fiktiv proces, hvor Sitrans FC410 Coriolis ønskes implementeret. Siemens Industrys funktionalitetskrav til demosoftwaren Siemens Industrys hardwareplatform Hardwareplatformen er baseret på det gamle demosoftware, undtagen tilføjelsen af webserver med user defined webpage. Siemens Industrys hardwareplatform tager ikke udgangspunkt i nogen specifik proces. Den tager udgangspunkt i, at demonstrere produktets funktionalitet for kunderne via panelet eller webserveren. Figur 2: Oversigt over Siemens Hardwareplatform (5) Side 12 af 48

14 Hardwareplatformen er opbygget som vist på figur 2. Figuren viser en 1212 C PLC udstyret med et CB1242 serielt kommunikationskort, der kommunikerer med en Sitrans FC410 Coriolis. Kommunikationen foregår over protokollen Modbus RTU RS485, der er en seriel kommunikationsprotokol, da dette er flowmålerens eneste interface. Figuren viser også, at demosoftwarens standard vil benytte en webserver med en user defined webpage som human machine interface. Webservere er en mulighed, der kun findes i Siemens 1200 og 1500 PLC er. Webserveren er en standard webpage, som Siemens har prædefineret fra fabrikationen. Formålet er, at data skal visualiseres under drift til diagnostisk formål, samt at give mulighed for, at lave en user defined webpage. Denne user defined webpage er en mulighed for, at lave en hjemmeside, der er bundet sammen med PLC ens kode. Det betyder, at hjemmesiden vil være projektets human machine interface. Ligesom et SCADA system f.eks. kan være det. Figuren viser også, at det skal være muligt, at købe et touchpanel for de kunder, der ønsker at tilgå samme muligheder på panelet som på webserveren. Dette skyldes, at det ikke er alle kunder, der ønsker at benytte webserveren som HMI for deres projekt. Programmets funktionalitet Figur 3: Flowchart over webserver/panel (6) På baggrund af mine anskuelser af den kvalitative data, har jeg udarbejdet et flowchart, vist ved figur 3. Figuren viser de overordnede funktioner, der vurderes at Siemens Industry ønsker på baggrund af den kvalitative empiri. Flowchartet viser en main menu, hvor det er muligt at skifte skærmbillede til den funktion, man ønsker at benytte. Side 13 af 48

15 Drift Dette skærmbillede skal visualisere selve driftssituationen for brugeren, så vedkommende kan danne sig et overblik over processen. Til dette vil Siemens Industry have, at procesværdierne, masseflow, volumenflow, densitet og temperaturen på procesmediet er tilgængeligt på dette skærmbillede. Dette skyldes samtidigt, at Siemens Industry generelt ønsker, at vise produktet virker (7). Siemens ønsker desuden, at flowmålerens frame temperatur skal være en del af disse værdier som vist på figur 4. Dette skyldes, at det er relevant information i forhold til spændinger i flowmålerens stålkonstruktion, da spændingerne kan påvirke resonansfrekvensen i flowmåleren. Dette kan i yderste tilfælde påvirke målingerne, hvis man har meget skiftende processer hvor temperaturen varier. Derudover vurderer de også, at der er et sikkerhedsmæssig aspekt i, at kende frame temperaturen, da man herved kan vurdere, om man vil forbrænde sig ved berøring. Det kan være relevant i en vedligeholdelsessituation, hvor anlægget er lukket ned for, at foretage vedligehold. (9). Siemens Industry ønsker desuden, at totalizeren skal være en del af dette skærmbillede, da denne værdi er summen af flow, der er løbet gennem flowmåleren. Siemens vurderer desuden, at totalizeren skal være tilgængelig for de kunder, der ønsker at basere deres forebyggende vedligehold på denne. (10) Derudover ønsker Siemens Industry, at have mulighed for, at kunne nulstille totalizeren ligesom i det gamle demosoftware (11). Alarmer Skærmbilledet skal give brugeren en indikation af hvilken fejl, der har udløst alarmen, så vedkommende kan udbedre eller korrigere for dem. Derfor ønsker Siemens Industrys, at programmet overvåger de to alarmgrupper som vist på figur 5. Disse indikerer, om der fejl på flowmåleren. Dette skyldes, at de vil have en indikator for, om deres målinger er valide, og om der er fejl på flowmåleren. (12) Figur 4: Skærmbillede over procesværdierne fra det tidligere demosoftware (8) Siemens Industry ønsker endvidere, at funktionen skal alarmere brugeren om, at sensoren er ved, at stabilisere sig, da dette er noget, flowmåleren har behov for under opstart. Det skyldes, at Siemens Industry har oplevet kunder, der Figur 2 Skærmbillede over alarmgrupperne fra tidligere demosoftware Figur 5: Skærmbillede over alarmgrupperne fra det tidligere demosoftware (13) Side 14 af 48

16 ikke har ventet på, at sensoren har stabiliseret sig. Dette har resulteret i, at kunderne har haft problemer med, at sensoren ikke har kunnet stabilisere sig. (14) Siemens Industry ønsker desuden, at overvåge alarmgrupperne, da de mener, at nogle brugere kan bruge funktionen til andre ting end blot alarmer. Dette kan f.eks. være empty pipe alarmen, som Siemens Industry vurderer, at nogle brugere vil have til, at indikere om røret er tomt for væske. Det kan være relevant i en situation, hvor flowmåleren skal skiftes eller afmonteres pga. vedligehold. (15) Diagnose Dette skærmbillede skal give brugeren mulighed for, at se værdierne på driverstrømmen til svingspolen, amplituderne og frekvensen, som vist på figur 6. Det ønsker Siemens Industry grundet deres serviceteknikker. Det vil herved gøre det lettere for dem, at udføre service på produktet, samt at fejlfinde på det. (16) ID/identifikation Skærmbilledet skal gøre det muligt for brugeren, at visualisere hvilket produkt, der er tale om ved, at gøre produktets serie nummer tilgængeligt på dette skærmbillede. Det mener Siemens Industry er vigtigt, da de ser demosoftwaren som en mulighed for, at visualisere produktet og dets funktioner. Desuden vurderer Siemens Industry, at de vil kunne yde en bedre support, hvis kunden hurtigt kan oplyse dem om flowmålerens serienummer. Siemens Industry har givet udtryk for, at alle produktrelevante informationer, skal være på dette skærmbillede, som f.eks. flowmålerens firmware version. (9) Setup Fra skærmbilledet skal det være muligt for brugeren, at indstille opsætningen af flowmåleren korrekt, så den passer til brugerens applikation. Derfor vil Siemens Industry have mulighed for, at læse og indstille parametrene low massflow cutoff, low volumeflow cutoff, process noise damping filter og flowretningen, som vist på figur 7. (18) Siemens Industry ønsker endvidere, at kunne definere low Figur 3: Diagnose skærmbilledet fra det tidligere demosoftware (17) massflow og low volumeflow, da nogle brugere ønsker at definere disse grænseværdier. Grænseværdierne giver Figur 4: Setup skærmbillede fra det tidligere demosoftware (19) Side 15 af 48

17 brugeren mulighed for, at definere den nedre grænsen for, at masseflowet eller volumenflowet skal være for, at flowmåleren blot viser nul, da nogle kunder har implementeret produktet i et uroligt miljø. Det kunne f.eks. være et skib, hvor rystelserne kan påvirke måleren således, at den måler et lille flow, selvom der ikke er et. Derfor har man i Siemens Industry vurderet, at det skal være muligt for kunderne, at kompensere for dette. Man har vurderet, at der derfor skal være en grænseværdi for, hvor stort flow, der skal være før, at det vises på måleren. (20) Siemens Industry ønsker, at kunne definere hvilket process noise damping filter, som flowmåleren skal benytte sig af. Dette skyldes, at process noise damping filter kompenserer for stærkt pulserende flow, ændring af pumpehastigheder og store trykvariationer. Derfor vil Siemens Industry benytte denne funktion i flowmåleren, da de vurderer, at dette kunne have stor relevans for kunderne. Baggrunden for denne vurdering bygger på, at funktionen tillader kunderne specifikt, at kompensere for den pumpetype, som kunden benytter i processen. Dette betyder, at kunden kan indstille flowmåleren, så det passer specifikt til kundens proces. Herved kan kunden få valideret sine målinger. (21) Til sidst vil Siemens Industry have mulighed for at vende flowretningen på flowmåleren, da det ikke er alle processer, der har en fast flowretning. Nulpunktsjustering Fra dette skærmbillede skal det være muligt for brugeren, at benytte flowmålerens automatiske nulpunktsjustering. Derfor vil Siemens Industry have mulighed for, at læse zero point offset value, zero point standard deviation samt, at definere zero point adjustment time, som vist på figur 8. Desuden ønsker Siemens Industry, at det skal være muligt, at aktivere nulpunktsjusteringen med en knap. Dette skyldes, at flowmåleren er nulpunktsjusteret fra fabrikken til et procesmedie med samme densitet som vand. Det betyder, at kunder hvis procesmedie har en anden densitet, har behov for at kunne nulpunktjustere flowmåleren, så målingerne opnår høj validitet. Dette har Siemens Industry vurderet ville være en funktion, der vil komme kunderne til gode. (23) Figur 5: zero point adjustment skærmbillede fra det tidligere demosoftware (22) Puls Skærmbilledet skal give brugeren mulighed for, at benytte denne nye pulsfunktion som Siemens Industry efterspørger. Denne pulsfunktion er ny, da den ikke eksisterer i det tidligere demosoftware, men er en Side 16 af 48

18 feature, de vil have i det nye demosoftware. Siemens Industry ønsker, at funktionen skal levere en puls til et eksternt system, som f.eks. master PLC. Denne puls skal være et digitalt signal, hvor brugeren kan definere pulsbredden, samt hvilken enhed der udløser den. Disse enheder skal være summen af kg eller m 3, der er løbet igennem flowmåleren. Det skal være muligt for brugeren, at vælge hvilken af disse enheder, pulsen skal baseres på, samt hvor ofte pulsen udløses. Det betyder, at det skal være muligt for brugeren, at definere, at pulsen eksempelvist udløses for hvert 100 kg, der er løbet gennem flowmåleren. Siemens Industry ønsker desuden, at funktionen skal kunne levere max 1000 pulser per sekund, samt at huske hvor den er kommet til i tilfælde strømsvigt. Det betyder, at hvis pulsen eksempelvist er indstillet til, at skulle udløses for hvert 100 kg., og den er på 80 kg. ved et strømsvigt, skal funktionen ikke starte forfra, men blot tælle videre fra de 80 kg., når den starter igen. Siemens Industry forstiller sig, at pulsfunktionen skal baseres på totalizeren, rent programmellet. (24) Årsagen til at Siemens Industry ønsker denne funktion skyldes, at de vil tilbyde kunder, hvis gamle flowmålere leverede en puls, et alternativ. Det ønsker Siemens Industry, da de vurderer, at kunderne kan bruge pulsen til at overvåge summen af flow, der er løbet gennem flowmåleren. Siemens Industry vurderer endvidere, at nogle kunder vil basere handlinger i deres proces på pulsen. Dette kunne f.eks. være, at for hvert 1000 kg., der løber gennem flowmåleren, skal der foretages en stikprøvekontrol af procesmediet. (25) Denne funktion skal forstås som en feature, der skal lokke flere kunder til at købe netop dette produkt. Aerated Flow Fra dette skærmbillede skal det være muligt for brugeren, at benytte sig af funktionen Aerated flow. Siemens Industry har vurderet, at denne funktion er en nice to have feature, og at den kun skal medtages i demosoftwaren, hvis udviklingsforløbet tillader det. Derfor har Siemens Industry ikke været specifikke i deres krav til funktionen udover, at det skal være som i det tidligere demosoftware. (26) Siemens Industry ønsker funktionen, da den giver brugeren mulighed for at kompensere for luft i procesmediet. Siemens Industry vurderer, at der er en vigtig funktion, da luft i procesmediet kan gøre målingerne invalide. Det skyldes flowmålerens virkemåde, samt densitets forskel mellem luft og procesmediet, som påvirker målingerne. Desuden kan for meget luft i procesmediet tvinge flowmåleren til at stoppe sine målinger. (27) Side 17 af 48

19 Kundernes funktionalitetskrav til demosoftwaren Kundescenarie Dette kundescenarie er baseret på et fiktivt membranfiltreringsanlæg i fødevareindustrien, der skal producere proteinpulver af råmælk. Baggrunden for dette valg skyldes, at jeg tidligere i mit uddannelsesforløb har dimensioneret et sådan anlæg. Derfor vurderes det, at dette er et ideelt valg, da jeg har en større indsigt i denne anlægstype. Desuden nævnes det, at Sitrans FC410 Coriolis benyttes i fødevareindustrien (28), hvilket understøtter dette valg. Figur 6: Kundescenariets membranfilteringsanlæg (29) Figuren viser tre Sitrans FC410 Coriolis implementeret i det fiktive membranfiltreringsanlæg, der skal producere proteinpulver. Sensor 1 er placeret på strengen, hvor råmælken kommer ind i processen, da den skal måle forbruget af råmælk. Sensor 2 er placeret på strengen, hvor retentatet løber ud af processen og videre til senere bearbejdning. Det skyldes, at den skal måle mængden af retentat, der produceres, så der kan dannes et overblik over, hvor meget af råmælken der ender som produkt. Sensor 3 er placeret på strengen, hvor permeatet løber ud af processen, så den skal måle mængden af spild. Figuren viser en 1212 C PLC, der skal modtage og behandle data fra flowmålerne. Det er desuden muligt, at benytte panelet som HMI. Dette scenario tager udgangspunkt i, at PLC en er master og projektets eneste HMI er panelet. Dette skyldes, at kundescenariet ikke skal benyttes til, at vurdere hvilken hardware, der er at foretrække i dette tilfælde, men at vurdere, hvilke funktioner demosoftwaren skal indeholde. Side 18 af 48

20 Programmets funktionalitet Figur 7: Flowchart over panelet I kundescenariet (30) På baggrund af kundescenariet, er der blevet udarbejdet et flowchart, vist ved figur 10. Figuren viser de overordnede funktioner, der vurderes, at demosoftwaren skal indeholde. Flowchartet viser en main menu, hvor det er muligt at vælge, hvilken sensor man vil tilgår. Under dette terminalpunkt er det muligt, at skifte skærmbillede til den funktion, man ønsker at benytte. Drift Fra dette skærmbillede ønskes det, at procesværdierne, masseflow, volumenflow, densitet og temperaturen på procesmediet er tilgængeligt. Både Siemes Industry og undertegnede vurderer, at det vil skabe bedre overblik over processen. Disse data er ikke blot et værktøj til, at danne overblik over processen. De kan også være et værktøj til at optimere den. Det kunne f.eks. være, at man som maskinmester skulle undersøge, om det var rentabelt, at omdrejningsregulere pumperne. Her vil data som f.eks. volumenflowet gøre beregningen af pumpernes effektforbrug lettere at foretage, da dette er nødvendig jf. denne formel: P 3 = ρ g H Q (31). Side 19 af 48

21 Det vurderes desuden, at frame temperaturen skal være tilgængelig, da jeg deler Siemens Industrys vurdering angående sikkerhedsperspektivet. Dette skyldes, at smertereceptorerne i kroppen reagerer ved en temperatur på 45 C, hvilket er en indikator på vævsødelæggelse (32). Det har relevans, da temperaturerne kan overstige 45 C under skiftet fra produktion til rengøring. Det vurderes dog ikke, at processens temperaturer varierer så meget, at det skulle kunne påvirke målingerne. Dette skyldes, at den eneste variation, der vil blive skabt i anlægget, vil være under skiftet fra produktion til rengøring. Det antages, at den varierer fra 8 C, som råmælken anses at have, til de 50 C, som rengøringsvæsken anses at have. Derfor vurderes det, at funktionen kun skal være tilgængelig, baseret på et sikkerhedsmæssigt perspektiv, da variationen i temperaturen ikke kan anses for, at være markant nok til at påvirke målingerne. Totalizeren skal også være tilgængelig fra skærmbilledet, da kundescenariet lægger op til, at forbruget af råmælk, og produktionen af retentat og permeat skal måles. Dette skyldes, at disse data kan være interessante i forbindelse med overvågning af forbruget af råvarer, der bruges til at producere slutproduktet. Det er relevant for en virksomhed, der ønsker at nedsætte omkostningerne, da vareforbruget er en de vigtigste omkostningsarter (33). Det skal endvidere være muligt, at nulstille totalizeren, da det forbrug man vil kortlægge, muligvis kun skal være i en bestemt tidsperiode. Desuden skal det være muligt, at pause og starte totalizeren igen. Det skyldes, at det ikke ønskes at måle forbruget af rengøringsvæske under rengøringsprocessen, da flowmålerne skal måle forbruget af råmælk, og produktionen af retentat og permeat. Derfor ønskes der mulighed for at pause totalizeren før rengøringsprocessen startes, og starte totalizeren igen når produktionen genoptages. Alarmer Det skal fra skærmbilledet være muligt, at identificere fejlen, der har aktiveret alarmen, så det er muligt, at udbedre eller korrigere for den. Derfor ønskes det, at programmet overvåger de to alarmgrupper, men ikke som vist på figur 5, som Siemens Industry ønsker. Siemens Industrys løsning ønskes ikke, da det ville kræve, at operatøren ved, hvilke fejl der sætter de enkelte bit. Det vurderes, at det vil resultere i tidsspilde, da operatøren i så fald skal slå op i manualen for, at identificere fejlen, hver gang et bit bliver højt i en af de to alarmgrupper. Det vurderes, at det i værste tilfælde kunne forlænge Mean Down Time (MDT). Dette skyldes, at en af faktorerne der påvirker MDT, er fejlfinding på anlægget og dets komponenter. (34) Derfor ønskes det, at programmet skal informere operatøren om præcist hvilken fejl, der har forårsaget alarmen. Det skal være i form af en tekst, der beskriver fejlkoden, der har aktiveret alarmen. Det skyldes vurderingen om, at fejlfindingstiden kan nedsættes på denne måde, hvilket vil kunne nedsætte MDT. Det vil også kunne nedsætte fejlfindingstiden på fejl, der ikke tvinger anlæggets stop. Side 20 af 48

22 Diagnose Fra dette skærmbillede ønskes der mulighed for, at læse driverstrømmen til svingspolen, amplituderne og frekvensen. Det ønskes visualiseret på samme måde som Siemens Industry, da det vurderes, at funktionen vil kunne påvirke MDT i tilfælde af, at fejlen skal udbedres af Siemens Industrys eget personale. Det vurderes ikke, at funktionen er vigtig for eget servicepersonale, da dette ville kræve, at de har ekstra kendskab til produktets virkemåde. Det vurderes, at funktionen kan nedsætte fejlfindingstiden i de fejl, der kræver Siemens Industrys eget personale til at udbedre fejlen, hvilket kan nedsætte MDT. Setup Fra skærmbilledet skal det være muligt for operatøren, at indstille opsætningen af flowmåleren korrekt, så den passer til processen. Derfor ønskes der mulighed for, at læse og indstille parametrene low massflow cutoff, low volumeflow cutoff, process noise damping filter. Det vurderes, at den vigtigste del af denne funktion er process noise damping filteret, da det som nævnt tidligere, kompenserer for stærkt pulserende flow, ændring af pumpehastigheder og store trykvariationer. Disse ting kan i værste tilfælde påvirke målingerne, da et pulserende flow eksempelvist kan påvirke procesmediets indløb til flowmåleren. Dette er vigtigt ifm. flowmålerens virkemåde, da den måler på vibrationerne, skabt af procesmediets acceleration i de interne bøjninger i flowmåleren. Det betyder, at procesmediets indløb til flowmåleren er vigtig for målingerne. For at opnå høj validitet af målingerne, ønskes der mulighed for, at kompensere for disse faktorer. Det ønskes desuden, at have parametrene low massflow cutoff, low volumeflow cutoff tilgængeligt, grundet Siemens Industrys vurdering af, at rystelser i anlægget kan påvirke måleren. Derfor ønskes disse elementer integreret i funktionen, da det ikke er muligt for mig, at vurdere rystelsernes omfang i anlægget på nuværende tidspunkt. Der ønskes ikke en situation, hvor rystelserne kan komprimere målingernes validitet ved, at måleren logger et lille flow pga. rystelserne i anlægget. Derfor vurderes det, at det skal være muligt at definere disse grænseværdier for, at imødekomme denne problemstilling. Baggrunden for fravalget af, at kunne definere flowretningen skyldes, at anlægget har en fast flowretning. Der kan derfor ikke ses nogen relevans for denne parameter. Nulpunktsjustering Fra dette skærmbillede skal det være muligt for operatøren, at benytte flowmålerens automatiske nulpunktsjustering. Derfor ønskes der mulighed for, at læse zero point offset value, zero point standard deviation, samt at definere zero point adjustment time. Derudover skal der være en knap, der aktiverer nulpunktjusteringen. Dette er identisk med Siemens Industrys krav til funktionen, som vist på figur 8. Side 21 af 48

23 Funktion ønskes med i programmet for, at kunne indstille flowmåleren specifikt til processen. Dette skyldes, at der efterstræbes høj validitet på målingerne fra flowmåleren. Baggrunden for, at det skal være muligt, at definere zero point adjustment time skyldes, at denne faktor er vigtig i beregningen af nulpunktet. Dette er vist på figur 11, der viser formlen for beregningen af zero point offset value, der er nulpunktet. Zero point adjustment time er med til at definere variablen N i formlen, hvilket påvirker beregningen af zero point offset value, hvilket er X. Måden zero point adjustment time påvirker variablen N er ved, at tidsperioden for nulpunktjusteringen påvirker antallet af prøver, den tager under nulpunktjusteringen. Dette betyder, at hvis zero point adjustment time øges, stiger antallet af prøver tilsvarende, hvilket påvirker variablen N. (35) Formlen vist på figuren viser desuden, at des større N bliver, des mindre bliver zero point offset value, hvilket betyder, at nulpunktet bliver mere præcist. Beregningen af zero point offset value skal ske ved, at indstille variablen N og trykke på knappen, der aktiver beregningen af denne. Grunden til, at det skal være muligt, at læse zero point standard deviation skyldes, at den oplyser om væskens homogenitet. Den er en indikator for, om der er bobler eller partikler i procesmediet, der kan påvirke dens homogenitet. Denne information er vigtig, da det er ud fra dén, at man vurderer hvorvidt, der skal foretages en nulpunktjustering. (35) Figur 8: Beregning af nulpunkt (35) Aerated flow Det ønskes, at aerated flow-funktionen er tilgængelig på sammen måde som i det tidligere demosoftware. Dette skyldes, at aerated flow-funktionen kompenserer for luft i procesmediet, da dette vil påvirke målingerne. Funktionen beror i flowmålerens virkemåde, da resonansfrekvensen er en direkte funktion af densiteten. Det betyder, at densitetsforskellen mellem luften i procesmediet og procesmediet, vil påvirke resonansfrekvensen. Det vil have den konsekvens, at resonansfrekvensen ikke vil have et ensartede forløb, og det vil påvirke målingerne. Derfor ønskes denne funktion tilgængelig, da man ikke kan sikre sig mod, at der kommer luft ind i procesmediet. Der ønskes ikke en situation, hvor der kommer luft ind i procesmediet, som ikke kan kompenseres for, da det vil forringe målingernes validitet. Side 22 af 48

24 Udvikling af Minimum Viable Product Dette afsnittet vil belyse udviklingsforløbet af et minimum viable product (MVP) for demosoftwaren. Dette skyldes, at UDD har inkorporeret lean-startup i sin metodik. Det betyder, at der ifølge lean metodikken, skal udarbejdes en MVP for demosoftwaren. MVP en skal indeholde de essentielle funktioner, der er nødvendige for, at produktet kan introduceres for kunderne. Det er for, at involvere kunderne i udviklingsforløbet ved feedback. (1) Derfor vil minimumskravene til MVP en i dette afsnit tage udgangspunkt i funktionalitetskravene til demosoftwarens nævnt i det tidligere afsnit. Minimums krav Baseret på kundernes og Siemens Industrys krav til demosoftwarens indhold er følgende minimumskrav opstillet. Procesværdier tabel 1 (36) Modbus Adresse Data Type Parameter Default value/unit Value Range Access Level 3000 Real Masseflow Kg/s - Read only 3002 Real Volumenflow m 3 /s - Read only 3004 Real Densitet Kg/m 3 - Read only 3010 Real Temperatur c - Read only 3023 Real Frame temperatur c - Read only Totalizer tabel 2 (37) Modbus Adresse Data Type Parameter Default value/unit Value Range Access Level 2610 Real Totalizer value 0 Kg - Read only 2612 Uint Reset totalizer - Enter "1" to Write only reset 2613 Uint Pause totalizer - Enter "1" to Write only pause 2614 Uint Start totalizer - Enter "1" to start Write only Side 23 af 48

25 Access level tabel 3 (38) Modbus Adresse Data Type Parameter 404 Uint Adgangs niveau Default value/unit Value Range - 32 (logged in) 4 (logged out) Access Level Read only 413 Uint Login og log out - Write 2457 to login and write 0 to log out Write only Tabellerne viser, hvilke data programmet som minimum skal kunne læse, samt hvilke adresser den skal kunne skrive til. Skrivekommandoerne skal forstås således, at programmet skal skrive en default værdi, vist under value range, til flowmåleren så den f.eks. pauser totalizeren. Dette skyldes, at flowmåleren er udstyret med en intern styring, der kommunikerer med PLC en over Modbus RTU RS 485. Den default værdi, der aktiverer denne handling i flowmåleren, er defineret i produktets manual. Baggrunden for minimumskravene Baggrunden for at procesværdierne, vist ved tabel 1, er en del minimumskravene, skyldes demosoftwarens formål. Demosoftwarens formål er, at illustrere om produktet virker, samt hvordan det kan benyttes. Derfor er procesværdierne vigtige, da de er en indikator for, om produktet virker efter hensigten. Dette er vigtigt for Siemens Industry, da de vil bruge demosoftwaren til at vise produktets funktionalitet. Det er desuden vigtigt for kunderne, at de får en indikator på, hvordan produktet virker, så de kan få en idé til, hvordan produktet kan benyttes. Baggrunden for at totalizeren, vist ved tabel 2, er en del af minimumskravene skyldes udelukkende kundescenariet. Det skyldes kundescenariets primære grund for, at implementere Sitrans FC410 Coriolis. Denne primære grund er ønsket om, at måle forbruget af råmælk og produktionen af retentat og permeat. For at kunne efterleve dette krav, er det nødvendigt at inkludere totalizeren i minimumskravene. Det er vigtigt, at efterleve de primære krav, hvis man udvikler et minimum viable product i et User Driven Development forløb. Dette skyldes, at udviklingsmetoden UDD påkræver, at der udvikles et MVP, der opfylder minimumskravene. Dette er vigtigt for det videre udviklingsforløb i UDD, da det tager Side 24 af 48

26 udgangspunkt i feedback fra slutbrugerne, der benytter MVP en. Denne feedback fra slutbrugerne er baggrunden for, at MVP en skal opfylde slutbrugernes minimumskrav. Dette skyldes, at hvis MVP en ikke opfylder disse minimumskrav, vil slutbrugerne heller ikke benytte MVP en. Dette kan resultere i, at udviklingsforløbet går i står pga. af manglende feedback til at videreudvikle produktet. (1) Baggrunden for at access level, vist ved tabel 3, er en del af minimuskravene, skyldes flowmåleren. Dette skyldes, at den påkræver, at der logges ind før andre skrivekommandoer kan anerkendes. Det betyder, at programmet skal skrive en default værdi til modbus adressen 413 for at logge ind. Dette er nødvendigt for, at kunne benytte andre skrivekommandoerne, f.eks. dem i totalizeren, vist i tabel 2. Side 25 af 48

27 Minimum viable product Denne del af afsnittet vil belyse, hvordan MVP en er blevet udarbejdet på baggrund af minimumskravene. Afsnittet vil belyse MVP en fra PLC-programmets side samt dets human machine interface. PLCprogrammet vil blive udarbejdet med inspiration fra bogen Logisk styring med PLC relæteknik og digital elektronik af Thomas Heilmann (39). Bogen, der benyttes i dette afsnit er 5. udgave fra 2008 og udgives af forlaget Heilmanns forlag. Bogens validitet kan diskuteres, idet forfatteren samtidigt ejer det forlag, som har udgivet den. Det kan betyde, at kilden ikke har været igennem samme kritiske revision som trykte kilder, der skal godkendes af et af forfatteren uafhængigt forlag. Bogen vurderes dog at være valid, da den indgår som en del af pensummet på Aarhus Maskinmesterskole. Det antages, at skolen som institution forholder sig kildekritisk til deres undervisningsmateriale. PLC programmet PLC-programmet vil være udviklet ved, at benytte struktureret programopbygning. Dette skyldes, at der kan være store fordele ved dette, som f.eks. følgende: Programmeringsarbejdet deles op i blokke Arbejdet kan deles blandt programmører Opbygningen af programmet bliver overskueligt Programmet er mere service venligt samt lettere at fortage rettelser eller ændringer i. Programafviklingen sker fra hovedprogrammet ved kald af nødvendige underprogrammer. (39) Baggrunden for, at benytte struktureret programopbygning ligger i den sidstnævnte fordel. Dette er vigtigt for udviklingsforløbet, da det er UDD, der benyttes. Det betyder, at der kommer mange rettelser eller ændringer løbende i forløbet. Side 26 af 48

28 Kalde strukturer Figur 9: Kaldestrukturen af MVP'en (40) Kaldestrukturen, vist ved figur 12, er over MVP en og den viser, at FB FC410_Flowmåler kaldes fra programmets hovedprogram. Derudover viser figuren, at der fra underprogrammet FB FC410_Flowmåler kaldes to yderlige underprogrammer. Underprogrammet FC410 INIT_Modbus indeholder en standard instruktion, som Siemens har udviklet til Modbus RTU. Instruktionen og blokkens eneste funktion er, at initialisere kommunikationen mellem PLC en og flowmåleren. Dette er nødvendigt for, at kommunikation mellem de to enheder kan ske. Underprogrammet FB FC410_MVP er blokken, der indeholder PLC-koden, der realiserer minimumskravene til programmet. Side 27 af 48

29 Funktions blokken FC410_Flowmåler Figur 10: Kaldet af FB FC40_Flowmåler (41) Kaldet af FB FC410_flowmåler der, vist ved figur 13, viser blokkens interface. Inputparametrene Port, Baud og Parity er alle parametre, som FC410 INIT_Modbus skal bruge for, at kunne initialisere kommunikationen mellem PLC en og flowmåleren. Port inputtet bruges til, at definere hvilket kommunikationskort, der benyttes til at kommunikere. Baud definerer hastigheden på kommunikationen mellem PLC en og flowmåleren. Parity definerer kommunikationen mellem PLC en og flowmåleren. Disse informationer skal bruges til instruktionen MB_COMM_LOAD, som er en instruktion Siemens tilbyder. Instruktionen konfigurerer kommunikationskortet, så kommunikationen mellem PLC en og flowmåleren kan lade sig gøre. Modbus adress benyttes af PLC koden i FB FC410_MVP. Modbusadressen, også kendt som modbus station adress, definerer hvilken enhed PLC en skal kommunikere med. Denne information skal bruges til instruktionen MB_Master, som er en instruktion Siemens tilbyder. Denne instruktion gør det muligt, at læse og skrive til flowmåleren. Interfacet Sensor_data er et InOut parameter, hvor det er muligt at tilknytte en brugerdefineret datatype. Denne datatype gør det muligt, at læse data fra blokken, samt at skrive til den. Side 28 af 48

30 Funktionen FC410 INIT_Modbus Figur 11: Kaldet FC410 INIT_Modbus (41) Dette er kaldet af FC410_INIT_Modbus inde fra blokken FB FC410_flowmåler, vist ved figur 14. Figuren viser en parametrerbare funktion, hvor den nødvendige data tilknyttes funktionens kode. Denne funktion eksekverer, som nævnt tidligere, instruktionen MB_COMM_LOAD til at initialisere kommunikationskortet. Denne instruktion skal være eksekveret før instruktionen MB_Master kan eksekveres. Det er derfor, at done bit et skal være sat før resten af koden eksekveres, som vist ved figur 15. For at se koden bag denne funktion, se bilag 1. Funktions blokken FC410_MVP Figur 12: kaldet af FB FC410_MVP (41) Dette er kaldet af FB FC410_MVP inde fra blokken FB FC410_flowmåler, vist ved figur 15. Figuren viser en parametrerbare funktionsblok med et interface med to input og en InOut. Inputtet Modbus adress definerer, som nævnt tidligere, hvilken enhed PLC en kommunikerer med. Dette input er nødvendigt for, at benytte instruktionen MB_Master. Inputtet HMI er en brugerdefineret datatype, der indeholder de nødvendig tags for at koden kan bindes sammen med projektets human machine interface. InOut Side 29 af 48

31 parameteren MVP er en brugerdefineret datatype, der tillader koden at skrive og læse mellem den. For at se koden bag denne funktion se i bilag 2. Den brugere defineret data type Sensor_data Figur 13: brugere defineret data type (41) Den brugerdefinerede data type Sensor_data, der skal tilknyttes funktionsblokken FC410_Flowmåler er vist ved figur 16. Figuren viser at Sensor_data består af to brugerdefinerede datatyper MVP og HMI, der tilknyttes funktionsblokken FC410_MVP, vist ved figur 15. Data typen HMI består blot af en række boolean tags, der skal benyttes til at lave et human machine interface til MVP en. Data typen MVP består af en række struct s, hvor koden skal læse fra samt skrive til. Dette kunne f.eks. være struct en proces value, hvor koden skriver de læste procesværdierne fra flowmåleren ned i. Side 30 af 48