Standaardiseren (het liefst multidisciplinair) is tegenwoordig een hot item. Verschillende afdelingen – zoals hardware, software en WTB – ontwerpen gezamenlijk gestandaardiseerde producten. We richten ons in deze blog op softwarestandaardisatie. Wat komt hier allemaal bij kijken? Waar moet je op letten? We lichten enkele aspecten toe.
Bij softwarestandaardisatie gaat het uiteindelijk altijd om keuzes maken. In software is namelijk nooit één juiste oplossing voor een probleem of vraagstuk; er zijn altijd meerdere juiste oplossingen. Dan is er niks moeilijks aan zou je denken. Maar juist het feit dat er meerdere mogelijkheden zijn, maakt het lastig om tot een softwarestandaard te komen waar iedereen achter staat. Elke oplossing heeft zo zijn eigen voor- en nadelen en elke software engineer heeft zijn eigen manier van werken. Dat maakt het lastig.
Over welke zaken moet je dan keuzes maken? Dat zijn onder andere:
- Structuur: welke gelaagdheid breng ik aan in de software?
- Afspraken over naamgeving/identificatie
- Alarmafhandeling: hoe sla je de alarmen op? Op welk niveau sla je de alarmen op? En staan alle alarmen van het gehele project op één plek, of staan ze per machinedeel/procesdeel op één plek?
- Parameters: hoe en waar sla je de parameters/instellingen op?
- HMI/SCADA: wil ik alle motoren, kleppen, metingen, etc. apart kunnen bedienen, bijvoorbeeld d.m.v. een pop-up?
.
Structuur
Eén van de eerste dingen waar je over na moet denken, is de structuur. Hoe wil ik de software opbouwen? Hoe wil ik de software gaan verdelen, in bijvoorbeeld secties of units? Of in een functionele decompositie? Om de structuur van de software te bepalen, bestaan er richtlijnen die kunnen helpen, zoals de ISA-S88 / PackML. Wanneer je een machinebouwer bent, kun je de software volledig afstemmen op de machines die je maakt. Wanneer je een systems integrator bent, kun je ervoor kiezen om één softwarestandaard te maken, die flexibel genoeg is voor verschillende klanten, met verschillende machines/processen. Het is uiteraard ook mogelijk om voor iedere klant een aparte standaard te maken.
In alle gevallen kan de onderste ‘laag’ van een installatie altijd gestandaardiseerd worden in de vorm van functiebouwstenen. Denk hierbij aan motoren, kleppen, etc. Dit zijn de control modules volgens de S88. Een motor aansturen werkt immers altijd hetzelfde. Met parameters (wel of geen rem bijvoorbeeld) kun je deze functiebouwsteen elke keer opnieuw inzetten, bij alle projecten.
De lagen daarboven standaardiseren is meestal wat lastiger. In deze lagen is de logica van een project aanwezig, zoals regelingen en stap-afloopjes. Voor een machinebouwer kunnen deze al voorgedefinieerd zijn, maar voor een systems integrator is dat lastiger. Toch kun je ook deze lagen standaardiseren in de vorm van een standaardopbouw van de functiebouwstenen van deze lagen. Er zit dan weliswaar nog geen logica in, maar de structuur en opzet zijn dan al wel bepaald. En dat is al heel wat waard.
.
Afspraken
Het is goed om afspraken te maken over bijvoorbeeld naamgevingen/variabelen. Laat je alle inputs van een functiebouwsteen beginnen met een kleine letter ‘i’, en de outputs met een ‘o’? Of beginnen de variabelen met een code waaraan je kunt zien wat voor type het is (bijv. de ‘b’ voor een boolean en ‘i’ voor een integer). Gebruik je vervolgens underscores in variabelen of schrijf je het CamelCase (dus of ‘Pomp_Auto_Start’ of ‘PompAutoStart’)?
Ook andere naamgevingen spelen een belangrijke rol. Bijvoorbeeld de naamgevingen voor de variabelen die gebruikt worden voor de koppeling naar I/O. En wat te denken van namen van functies en functiebouwstenen?
Andere zaken waarover je afspraken kunt maken:
- In welke taal wordt geprogrammeerd
- Commentaar van variabelen
- Commentaar en titel bij een netwerk
- Wel/geen mixed languages in één functiebouwsteen
- Wel/geen gebruik van globale variabelen in een functiebouwsteen
- Etc.
.
Functionele vragen
Er zijn ook functionele vraagstukken waarover je moet nadenken. Wil je bijvoorbeeld alle control modules apart kunnen bedienen vanaf HMI/SCADA? Dit zou kunnen d.m.v. een pop-up. Op het pop-up scherm is het mogelijk om een motor in handmatige modus te zetten, zodat de motor vanaf de pop-up aan- en uitgezet kan worden. Vervolgens zouden de volgende vragen kunnen rijzen: mag ik de motor in handbediening aanzetten als er alarmen zijn? Kan ik de parameters van de motor zomaar aanpassen of moet ik daarvoor ingelogd zijn met een bepaald niveau? Stuk voor stuk functionele vragen, waarbij het handig is om die in het voortraject van de standaardisatie al te beantwoorden.
.
Hardware
Ook over de hardware moet je goed nadenken. Je wilt bijvoorbeeld niet meerdere standaard functiebouwstenen maken voor verschillende merken frequentieregelaars. Beter is dan om bijvoorbeeld voor twee merken te kiezen en daarop de software op in te richten. Dan heeft de klant nog enige keus. Wil de klant persé een ander merk, dan is dat uiteraard nog steeds mogelijk. Alleen kun je dan geen gebruikmaken van je standaardfunctiebouwstenen, wat resulteert in een langere doorlooptijd van het project.
.
Tot slot: knopen doorhakken
We kunnen concluderen dat het definiëren van een standaard voor een softwareafdeling, waar iedereen achter staat, zeker haalbaar is. Je kunt lang over bepaalde keuzes discussiëren. Dit is goed, maar op een gegeven moment moeten er wel knopen doorgehakt worden. Het is daarom belangrijk dat er een verantwoordelijke wordt aangesteld die knopen door kan en mag hakken.
Als er op een gegeven moment een standaard ontstaat die door iedereen wordt gedragen, dan zullen de engineers meer tijd kunnen steken in de ‘specials’ van een project. Over de ‘standaard’ software hoeven ze niet meer na te denken, daar kunnen ze op vertrouwen. Dit komt ten goede van de kwaliteit en indirect dus ook in het terugbrengen van het aantal storingen (denk aan de storingsdienst). Heeft u al een breed gedragen softwarestandaard? Of heeft u een sparringpartner nodig bij het opzetten van een standaard?
Wij geven regelmatig webinars ten aanzien van dit onderwerp. Interessant? Sluit vooral aan!
English (UK)