[Algemeen] [SCADA] - Version control

[Armageddon_2k]

Beste mede Tweakers,

De situatie
Op het moment zijn we bezig met een SCADA project waarbij we gebruik maken van een template voor een tal van objecten. Het gaat daarbij om onderdelen zoals motoren, ventielen, lopende band enz.
Deze zijn gestandaardiseerd zo wel in de PLC als op SCADA.
De SCADA sofwtare is ingekochte software en is iets wat wij implementeren, niet programmeren.

De uitdaging
het SCADA heeft geen mogelijkheden tot versie beheer. SCADA heeft ook geen mogelijkheden tot het locken van basis objecten. Wij willen uiteraard voorkomen dat er aanpassingen worden gedaan in de basis objecten. Maar op technisch gebied, bied SCADA hier geen oplossingen voor. De basis objecten zijn niet 1-2-3 als flatfile in een source control te gooien, dus dat is helaas geen mogelijkheid.

De vraag
Hoe pakken jullie zo iets aan?
Het zal waarschijnlijk procedureel vast gelegd moeten worden, maar zijn hier methodes voor die al jaren succesvol toegepast worden, of moeten we het wiel zelf gaan uitvinden.

[wazzzaaa]

Over welk SCADA pakket en PLC gaat het hier ?

[Armageddon_2k]

We gebruiken een grote variëteit aan producten, voor zowel PLC als SCADA.
SCADA: inTouch, iFix, Cimplicity, WinCC, enz
PLC: Siemens, Rockwell, ABB, Beckhoff, enz.

Ook mede daardoor is de kijkrichting meer naar een procedurele dan technische oplossing.

[Basti504]

Soms is het mogelijk om ergens een soort van checksum uit te halen, zo weet bijvoorbeeld dat je bij Rockwell RSLogix een checksum van een AddOnInstruction kan trekken. Als dit nummer dan veranderd is weet je dat er iets niet pluis is.

Wat ik ook wel eens gezien is dat een programmeur al zijn objecten in de naam een versie nummer gaf, dus MotorDirect_V1.5 bijvoorbeeld.

Waar ik zelf wel voorstander van ben is om de code/condities/flowchart/layout HMI op papier te zetten en die als leidraad te houden. Wat je dan hebt is dat de master niet perse in Siemens geschreven en daardoor weer moeilijk naar Rockwell om te zetten is, maar dat de master een tekst document is en de Siemens en Rockwell code een uitwerking daarvan zijn. Met eventueel link naar versie van het master document.

Als er iets niet klopt hoef je enkel het document op tafel te leggen en te kijken OF er een ontwerpfout in het document zit OF de uitwerking in bijvoorbeeld Rockwell foutief is.

[Alain]

Ik loop hier ook tegenaan. Voor ons SCADA pakket is een version control applicatie beschikbaar, maar deze is erg duur.

Ik heb bij het huidige project SVN gebruikt, maar dit is niet echt handig. Als je de binaire bestanden niet meeneemt in de version control, dan is het enigzins werkbaar. Toch treden er bij sommige veranderingen rare dingen op. Bij een update laat ik alle clients alles opnieuw compileren om zeker te zijn dat er geen problemen optreden.

[Armageddon_2k]

Maar dat moet dan net aansluiten bij dat type SCADA pakket. Wel zonde dat er vanuit de leveranciers niet een dergelijk iets is gemaakt. Ik ken weinig SCADA pakketten die het doen.

[L0Lig]

Ook al is het geen feature van het SCADA pakket zelf, version control blijft een must.

Voor version control van de applicatie gebruiken wij Visual Source Safe, dit is inderdaad erg gedateerd maar doet het nog prima.
Hierin slaan wij alleen volledige en gecompileerde versies op.

Het locken van de basis onderdelen doen wij door middelvan een geinclude project, dit geinclude project is de library met alle basisfuncties.

Het is procedure dat een engineer geen wijzigingen maakt in deze library, bugfixes, feature request kunnen worden aangevraags bij de SCADA helpdesk en worden meegenomen in de volgende release.

[farlane]

Een van de grote voordelen van een SCM pakket is dat je de veranderingen in de source kunt bekijken ( dat kunnen dus ook documenten zijn etc ). Dit help enorm bij het zoeken naar bugs etc.
Een ander voordeel is het kunnen branchen en mergen etc als er met meerdere mensen aan hetzelfde project wordt gewerkt.

Kun je bij de manier waarop jullie het gebruiken dit nog doen?

[L0Lig]

Omdat er een compileerd pakket is opgeslagen zijn veranderingen lastig er uit te halen.
Het type bestanden is moeilijk met elkaar te vergelijken aangezien het niet alleen om code gaat.
Het naar boven halen van welk bestand wanneer is gewijzigd is de beschikbare informatie.

Mergen en branchen gebruiken wij niet gezien de interconnecties tussen alle types bestanden, we gebruiken het puur voor check-in, check-out er zal daarom maar 1 iemand in het bestand aan het werk zijn.

[drm]

Ik heb geen ervaring met dit specifieke vakgebied, maar wat ik wel weet is dat commit messages minstens zo belangrijk zijn als de changesets zelf. Dus als je binaries moet committen, heb je niet per se veel aan het feit dat je changes zelf aan versiebeheer onderhevig zijn, maar je weet wel wie wat wanneer gedaan heeft en waarom.

Daar kun je procedures voor verzinnen, bijvoorbeeld door een vast format voor commit messages te verzinnen en met heldere branch-naamgeving en rechten te werken. Daar kun je ook handige changelogs uit distilleren, en als je dit op de een of andere manier aan een build-integration systeem kan hangen en je kan het continu (automatisch) testen, dan kom je een heel eind.

[Snowhite0901]

Het is wat lang geleden, maar ik wilde dit topicje toch maar weer een schopje geven want ik zit met dezelfde vraag. Bij mijn vorige werkgever gebruikten we versiondog, maar die hebben nu geen koopmogelijkheden meer, en maar 1 soort abonnement van €1400 per maand.
Ik overweeg git/svn te gaan gebruiken zoals hierboven aangegeven tenzij iemand nog een beter idee heeft?

[RobIII]

Ipv een bejaarde oude koei uit de sloot te trekken, open even een nieuw, eigen topic a.u.b.