V2018-oppg-1

Oppgave 1

Basert på dei korte skildringane frå teknisk sjef vert det ein diskusjon om korleis dei ulike einingane skal kommunisera med kvarandre. Kvar av dykk vert beden om å foreslå ei løysing som eit grunnlag for diskusjon.

Lag en skisse over anleggets kommunikasjonstopologi og begrunn valgene dine.

Kommentar.

Utkast 1

Hvorvidt kamera skal plasseres nede på Ethercat feltbus eller oppe på Ethernet lokalnett, det kommer jo an på om programmet for bruk av kameraet kjører på Kuka robot eller på Omron PLS. VI legger til grunn at denne program modulen kjører på Omron PLS.

Ett sted i dokumentasjonen så går det fram at frekvensomformerne bare kan styres/ kommuniseres mot via RS485 Bus, et annet sted så står det at man også kan bruke Ethercat. I tegningen over så bruker vi Ethercat, og i tegningen under så benytter vi RS485.

Begrunnelse for valg av topologi.

Vi kan i praksis bruke «Purdue modellen» som en sikkerhetsmessig referansemodell som er en del brukt for ICS – Industrielle kontrollsystemer. Vi befinner oss på de forholdsvis lavere nivåene i forhold til modellen, og det ligger naturlig til rette for å organisere nettverket i form av et lokalnett (Ethernet) og en felt-buss (Ethercat).

Sikkerhets PLS med tilhørende sikkerhetssystem skal i størst mulig grad kjøre som et selvstendig og uavhengig system. Vi legger det derfor opp på samme «nivå» som lokalnettet, selv om det også er mulig å plassere sikkerhets-PLS på feltbus-nivå. (Dette bør sjekkes nærmere, dokumentasjonen viser også sikkerhets-PLS koblet opp på feltbus nivå.)

Her er litt mer info for de som ønsker å lære litt mer i dybden omkring «Automashonspyramiden»:

Når det gjelder problemstillingen rundt lagring av historiske data så er dette anlegget så forholdsvis lite at det vil være lite naturlig med en egen databaseserver. Lagring av data bør heller kunne inngå som en naturlig «tilleggsfunksjon» for PLS eller HMI (Data lagres typisk på en minnepinne plassert i HMI.)

Ved at PLS støtter OPC, som er en slags standardisert serverfunksjon for utveksling av kontrolldata, så vil det nok også være teknisk mulig å sette opp en egen separat database server som lagrer historiske driftsdata ved å hente ut driftsdata fra PLS’ens OPC server.

Når det gjelder problemstillingene rundt «cyber security» og mulighetene for hacking eller sabotasje, så har vi valgt en løsning med et lite avgrenset lokalnett, som er plassert bak en NAT-router. Dette gir i utgangspunktet en forholdsvis høy grad av sikkerhet ved at NAT-routeren også fungerer som en forholdsvis effektiv brannmur. Det er forholdsvis vanlig å gjennomføre oppdateringer av programvare via Internett, så vi finner det sannsynlig at det bør finnes en slik mulighet for oppkobling mot Internett.

Det står ikke nevnt i oppgaven at anlegget skal kunne styres via Internett, men vi har skissert også dette som en mulighet. En slik mulighet for fjernstyring medfører også en risiko i forhold til «Cyber Security» (Hacking/Sabotasje), som må risikovurderes for seg.

Nå er dette bare et veldig lite nettverk, men dersom vi skulle ønske å bygge ut dette nettverket, eller koble det sammen med andre nettverk. Da ville det være aktuelt (og nødvendig) å dele nettverket opp i flere nettverkssegmenter. Til det så vil vi typisk bruke en eller flere «Layer 3» konfigurerbare switcher for å segmentere nettverket opp i flere sikkerhetssoner.

Bare for å ha nevnt dette i en «bisetning» så finnes det også en referansemodell for det som går på «Cyber Security» som heter «The Cyber Kill Chain«.

Litt om kommuniasjon til/fra Omron PLS (for den spesielt interesserte).

Når det gjelder hvordan Omron PLS utveksler data med HMI og annet tilkoblet utstyr, så opplyser man at Omron PLS kjører CX-server. Det er litt uklart om dette er det samme som Omron CX OPC server. Grunnleggende prinsipper skulle uansett bli noenlunde de samme.

Enkelte PLS’er med modellnummer som ender på 20 kan også ha støtte for SQL server.

(Data kan enklere og billigere bli lagret på for eksempel USB pinne på HMI.)