76
KKS-SIGNAALITUNNUSJÄRJESTELMÄN KEHITTÄMINEN LAITOSSUUNNITTELUA VARTEN Tomi Kytö Opinnäytetyö Marraskuu 2018 Sähkö- ja automaatiotekniikan koulutus Automaatiotekniikka

KKS-signaalitunnusjärjestelmän kehittäminen

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

KKS-SIGNAALITUNNUSJÄRJESTELMÄN

KEHITTÄMINEN LAITOSSUUNNITTELUA

VARTEN

Tomi Kytö

Opinnäytetyö

Marraskuu 2018

Sähkö- ja automaatiotekniikan koulutus

Automaatiotekniikka

TIIVISTELMÄ

Tampereen ammattikorkeakoulu

Sähkö- ja automaatiotekniikan koulutus

Automaatiotekniikka

KYTÖ, TOMI:

KKS-signaalitunnusjärjestelmän kehittäminen laitossuunnittelua varten

Opinnäytetyö 76 sivua, joista liitteitä 26 sivua

Marraskuu 2018

Tämän opinnäytetyön toimeksiantajana oli Valmet Technologies Oy. Työssä yhdenmu-

kaistettiin Valmetin voimalaitossuunnittelussa käytettävien instrumenttien ja laitteiden

positiointiin liittyvien signaalitunnusten käyttö. Signaalitunnusten lisääminen projektei-

hin oli tehty aiemmin käsin suunnittelun ohessa, mikä vei huomattavasti aikaa, joten syn-

tyi tarve kehittää tapa nopeuttaa ja yksinkertaistaa prosessia.

Signaalitunnuksista koottiin lista, joka sisältää yleisimmät tunnukset, joita laitossuunnit-

telussa tarvitaan. Lisäksi tunnuspositioinnista kirjoitettiin ohje, jonka tarkoituksena on

tukea suunnittelutyötä. Näiden ohjeiden tarkoituksena on myös toimia asiakkaille esitet-

tävänä referenssinä, josta käy ilmi Valmetin tapa käyttää signaalitunnuksia.

Varsinaisen työskentelyn nopeuttamiseksi ja helpottamiseksi signaalitunnukset syötettiin

Comos-suunnitteluohjelman mallikantaan, josta ne kopioituvat tuleviin projekteihin eikä

näin ollen positiointia ole tarpeen tehdä jokaiseen projektiin erikseen. Signaalitunnusten

syöttämisessä käytettiin apuna signaalitunnuslistaa ja aiheesta kirjoitettua ohjeistusta.

Ohjeistusta päivitettiin tunnusten syöttämisen yhteydessä aina epäselvien tapausten koh-

dalla.

Työn tuloksena syntyi hyvä pohja positiointia varten. Teoriassa uudistetut signaalitun-

nukset vastaavat riittävän hyvin suunnittelun tarpeita tällä hetkellä, mutta todellisen ar-

vion niiden toimivuudesta voi antaa vasta muutaman projektin jälkeen, jolloin huomataan

uuden järjestelmän toimivuus käytännössä. Oletettavasti järjestelmä tulee vaatimaan jat-

kokehitystä tulevaisuudessa, mutta valmiiksi tehtyjen muutosten avulla tämä tulee ole-

maan helpompaa.

Asiasanat: voimalaitos, toiminnallinen suunnittelu, signaalitunnukset

ABSTRACT

Tampereen ammattikorkeakoulu

Tampere University of Applied Sciences

Degree Programme in Electrical and Automation Engineering

Automation Engineering

KYTÖ, TOMI:

The Development of KKS Signal Code System for Plant Design

Bachelor's thesis 76 pages, appendices 26 pages

November 2018

This thesis was commissioned by Valmet Technologies Oy. The purpose of the thesis

was to simplify the use of signal codes for the positioning of instruments and devices in

Valmet's functional design for power plants. Adding signal codes to projects had previ-

ously been handled during the design process by the engineer, which took a considera-

ble amount of time. Therefore, there was a great need to develop a way to speed up and

simplify the process.

A list of the signal codes was assembled. The list contains the most common codes

needed for plant design. In addition, a guide was written about the signal codes to sup-

port the engineers' work. The purpose of this guide is also to serve as a reference for

customers to show how Valmet uses the signal codes.

To speed up and simplify actual work, the signal codes were entered to the Comos base

model, from which they will be copied to future projects, and therefore there will be no

need for positioning in each project separately. The list of codes and the positioning

guide were used to input the signal codes. The guide was updated during the entering of

codes whenever unclear cases occurred.

As a result of this project, a good foundation for positioning was created for the future.

Theoretically, the signal codes created in this study are sufficient for the designing pro-

cess at the moment, but a real estimate of their functionality can only be made after the

new system has been tested in practice in a few projects. It is likely that the system will

require further development in the future, but with the changes made during this project

it will be much easier.

Key words: power plant, functional design, signal codes

4

SISÄLLYS

1 JOHDANTO ...................................................................................................... 7

2 VALMET OYJ .................................................................................................. 8

3 KKS-TUNNUSJÄRJESTELMÄ ...................................................................... 9

3.1 Historia ja julkaisut .................................................................................... 9

3.2 KKS-koodauksen käyttö laitossuunnittelussa .......................................... 10

3.3 Tunnuksen rakenne .................................................................................. 11

3.3.1 Tunnusten tyypit ........................................................................... 11

3.3.2 Tunnuksen erittelytasot ................................................................. 12

3.4 Signaalitunnukset ..................................................................................... 15

3.5 Esimerkkejä Valmetin tunnuksista .......................................................... 16

3.6 Signaalien käyttö Valmetin laitossuunnittelussa ..................................... 17

3.7 Signaalitunnusten käyttö .......................................................................... 18

4 ERILAISET JÄRJESTELMÄFILOSOFIAT .................................................. 19

4.1 Dokumenttipohjainen sovellus ................................................................ 19

4.2 Tietokantapohjainen sovellus .................................................................. 19

4.3 Oliopohjainen sovellus ............................................................................ 20

5 COMOS ........................................................................................................... 21

5.1 Visual Basic -skriptit ............................................................................... 22

5.2 Ohjelmiston rakenne ja käyttö Valmetilla ............................................... 23

5.2.1 Base-objektit ja standarditaulut ..................................................... 26

5.2.2 Objektien attribuutit ...................................................................... 26

5.3 Työskentelytasot ...................................................................................... 29

5.4 Kyselyt ..................................................................................................... 30

5.5 Mallikanta ................................................................................................ 31

6 TUNNUSJÄRJESTELMÄN LUOMINEN .................................................... 32

6.1 Signaalitunnuslista ................................................................................... 32

6.2 Suunnitteluohje ........................................................................................ 36

7 MALLIKANNAN PÄIVITYS ........................................................................ 38

7.1 Muutosten yleiset vaikutukset ................................................................. 38

7.2 Mallikannan standarditaulujen päivitys ................................................... 39

7.3 Signaalitunnuksiin liittyvät mallikannan objektien attribuutit ................. 40

7.4 Mallikannan Base-objektien päivitykset .................................................. 40

7.4.1 Objektien attribuuttien lisääminen asetusikkunaan ....................... 41

7.4.2 Objektien esitys kuvissa ................................................................ 42

7.5 Yksittäisten signaalitunnusten lisäys ....................................................... 44

8 COMOKSEN ONGELMAT JA JATKOKEHITYS ....................................... 47

5

9 POHDINTA ..................................................................................................... 48

LÄHTEET ............................................................................................................. 49

LIITTEET ............................................................................................................. 51

Liite 1. Lista signaalitunnuksista ..................................................................... 51

Liite 2. Ohje KKS-signaalitunnusten käyttöön ............................................... 61

6

LYHENTEET JA TERMIT

BMS Poltinhallintajärjestelmä (Burner Management System)

CAD Tietokoneavusteinen suunnittelu (Computer-aided design)

DCS Hajautettu ohjaus järjestelmä (Distributed Control System)

I/O Input/Output, tiedonsiirto komponenttien välillä

KKS Voimalaitoksissa käytettävä tunnistusjärjestelmä (Kraftwerk-

Kennzeichensystem)

PI-kaavio Putkitus- ja instrumentointikaavio

Positio Suunnittelussa käytettävä aakkosnumeerinen koodi, jolla ero-

tellaan laitoksen osat toisistaan

SIS Turva-automaatiojärjestelmä (Safety instrumented system)

Skripti Lyhyehkö tietokoneohjelma, jonka avulla annetaan komen-

toja tietylle ohjelmalle tai järjestelmälle tarkoituksena auto-

matisoida työvaiheita

7

1 JOHDANTO

Tässä opinnäytetyössä luotiin Valmetin voimalaitossuunnitteluosaston käyttöön suun-

nattu laitosten osien positiointia koskeva ohjeistus ja päivitettiin tarvittavat positiotun-

nukset yleiseen mallitietokantaan. Työ koskee erityisesti positioiden loppuosia eli signaa-

litunnuksia. Työn kirjallisessa osuudessa käsitellään teoriassa laitosten positiointia ja sii-

hen liittyviä ohjeistuksia ja standardeja sekä perehdytään Valmetin käytössä olevaan Co-

mos-suunnitteluohjelmaan, sen rakenteeseen ja käyttöön laitossuunnittelussa.

Signaalitunnusten määrittämisen haasteita ovat yritysten toisistaan poikkeavat käytännöt,

vanhojen toimintatapojen uudistaminen ja Comos-ohjelmiston mukauttaminen tunnusten

syöttämistä varten. Työssä on otettu huomioon teknisesti soveltuvien ratkaisujen lisäksi

myös inhimilliset tekijät, jotka vaikuttavat suunnittelutyön laatuun ja nopeuteen ja sitä

kautta myös toiminnan taloudellisuuteen ja sujuvuuteen.

Työ on jaettu kahteen suurempaan kokonaisuuteen, jotka ovat tunnusjärjestelmän suun-

nittelu ja ohjeistuksen laatiminen sekä käytännön toteutus Comoksessa. Suunnitteluosa

sisältää vanhojen ohjeistuksien ja standardien tutkimista ja soveltamista ja aiempien pro-

jektien läpikäymistä. Toteutukseen liittyy Comoksen ominaisuuksien muokkaaminen

koodaamisen avulla ja tunnusten syöttäminen järjestelmään manuaalisesti.

8

2 VALMET OYJ

Valmet Oyj on suomalainen yritys, joka keskittyy sellu-, paperi- ja energiateollisuuden

teknologiaan, automaatioon ja palveluiden toimittamiseen. Valmetilla on taustallaan yli

200 vuoden kokemus teollisista operaatioista ja nykyiseen muotoonsa se on kehittynyt

lukuisten yritysten yhdistymisten ja jakautumisten kautta. Historiansa aikana yhtiö on

valmistanut esimerkiksi junia, lentokoneita, kelloja, traktoreita ja paperikoneita. Nykyi-

nen Valmet syntyi, kun se jakautui Metso Oyj:stä vuonna 2013 erilliseksi pörssiyhtiöksi.

(Valmet yrityksenä 2018.)

Valmet toimii noin 30 maassa ympäri maailman ja työllistää yli 12000 ihmistä. Yhtiön

pääkonttori sijaitsee Espoossa. Muut toimipaikat Suomessa sijaitsevat Tampereella, Jy-

väskylässä, Lapualla, Järvenpäässä, Porissa, Ulvilassa, Juankoskella, Valkeakoskella,

Kajaanissa ja Raisiossa. (Valmetin toiminnot Suomessa 2018). Vuonna 2017 Valmet

Oyj:n liikevaihto oli noin 3,1 miljardia euroa ja tilikauden tulos noin 127 miljoonaa euroa.

Yhtiön toimitusjohtaja on Pasi Laine. (Avainluvut 2018.)

Valmetin liiketoimintaan kuuluu neljä päälinjaa:

- Palvelut

- Automaatio

- Sellu ja energia

- Paperit. (Liiketoiminnat 2018.)

Palvelut ja Automaatio ovat vakaata liiketoimintaa, sillä niiden markkinat perustuvat hi-

taaseen ja tasaiseen kasvuun, asennettuun laitekantaan ja tehtaiden käyttöasteeseen. Sellu

ja energia ja Paperit -liiketoiminta perustuu projektiluonteisuuteen ja on riippuvainen yri-

tysten investoinneista uusiin laitteisiin ja laitoksiin. Tulevaisuudessa kaikkien liiketoi-

minta-alojen kysyntää lisää kasvava sellun, energian, pehmopapereiden, kartongin ja pa-

perin tuotanto, kysyntä entistä tehokkaammille prosesseille, tehokkaammalle ylläpidolle

ja kunnossapidolle, ikääntyvä laitekanta ja automaatiojärjestelmät, älykkään teknologian

kysyntä, kasvava energiankulutus, kestävän kehityksen tukeminen ja ostovoiman ja elin-

tason kasvu kehittyvillä alueilla. (Liiketoiminnat 2018.)

9

3 KKS-TUNNUSJÄRJESTELMÄ

Lyhenne KKS tulee saksan kielen sanoista Kraftwerk-Kennzeichensystem (eng. Identifi-

cation System for Power Plants), joka suomeksi käännettynä tarkoittaa voimalaitosten

yksilöintijärjestelmää (KKS Identification 2008, 2). Tällä tarkoitetaan positiointi- eli ni-

meämisjärjestelmää, jonka avulla voidaan voimalaitossuunnittelussa yksilöidä laitokset

sekä niiden tilat, osastot, järjestelmät, mittaus- ja säätöpiirit, laitteet, instrumentit ja kom-

ponentit. Positioinnin tarkoituksena on antaa jokaiselle laitoksen osalle uniikki tunnus,

jolloin niiden etsiminen, muokkaaminen ja hallinnointi tietokannassa helpottuu, sillä kah-

della laitoksen osalla ei voi olla samaa tunnusta. Järjestelmän rakenne ja tunnukset on

säädetty ohjeissa VGB B105 ja B106 ja ne perustuvat standardiin IEC 81346, joka sisältää

periaatteita ja sääntöjä järjestelmien teknisten kohteiden, signaalien ja dokumenttien ni-

meämisestä.

Järjestelmää kehitettäessä on otettu huomioon seuraavat vaatimukset:

- Soveltuvuus mihin tahansa voimalaitostyyppiin

- Soveltuu kaikkiin tekniikan alan sektoreihin

- Riittävän hyvä erottavuus

- Soveltuu suunnitteluun, rakentamiseen, käyttöön ja ylläpitoon

- Ottaa huomioon kansainväliset standardit

- Voidaan laajentaa uusille voimalaitoksille

- Ei ole sidottu tiettyyn kieleen, jotta saavutetaan kansainvälisyys. (KKS

Identification 2008, 2.)

3.1 Historia ja julkaisut

KKS-järjestelmä sai alkunsa vuonna 1969 julkaistusta artikkelista ”System zur Kenn-

zeichnung von Geräten und Anlagenin Wärmekraftwerken” (eng. System for the desig-

nation of components and plant equipment in thermal power plants). Artikkelissa esitel-

tiin nimeämisjärjestelmä, jota kutsuttiin nimellä AKS (Anlagenkennzeichnungssystem,

eng. Plant Designation System). Järjestelmä oli yhdistelmä monista muista aiheeseen liit-

tyvistä standardeista. (Kaiser, Königstein & Müller 2007, 1–2.)

10

KKS-järjestelmän kehitti alun perin AKS-järjestelmän pohjalta saksalainen VGB Power-

Tech vuosina 1975-1978. Yhtiön tarkoituksena oli alusta asti kehittää ja valvoa järjestel-

mään liittyvää palvelua ja tarjota lisäpalvelua yrityksille. KKS-ohjeen ensimmäinen pai-

nos julkaistiin vuonna 1978. (Kaiser, Königstein & Müller 2007, 1–2.)

Myöhemmin VGB on kehittänyt nimeämisjärjestelmäänsä eteenpäin ja julkaissut KKS:n

jatkokehitysversion RDS-PP:n (Reference Designation System for Power Plants), joka

tarjoaa laajennuksia vastaamaan nykyaikaisia voimalaitossuunnittelun vaatimuksia. Siinä

on otettu huomioon esimerkiksi sähköntuotannossa käytettävät hajautetut laitosjärjestel-

mät. RDS-PP:tä kehitetään edelleen ja siitä ollaan tekemässä itsenäistä ISO-standardia.

(Kaiser, Königstein & Müller 2007, 1–2.)

3.2 KKS-koodauksen käyttö laitossuunnittelussa

Laitossuunnittelussa KKS-koodausta voidaan hyödyntää koko laitoksen elinkaaren ajan

suunnittelussa, laitehankinnassa, rakentamisessa, tuotannossa, ylläpidossa, huollossa ja

romuttamisessa (Nanjing Luculent Co n.d).

Suunnitteluvaiheessa laitoksen osalle annetaan yksilöivä tunnus, joka voidaan esittää kaa-

vioissa, kuvissa ja signaali-, laite-, kaapeli- ja kulutuspisteluetteloissa. Näiden dokument-

tien pohjalta tehdään laitehankinnat. Hankintojen yhteydessä on eduksi, jos laitetoimittaja

merkitsee tunnuksen fyysisesti laitteen runkoon tai erilliseen positiolaattaan. Näin helpo-

tetaan laitteiden yksilöintiä jo valmistus- ja kuljetusvaiheessa, sillä samat tunnukset voi-

daan liittää esimerkiksi pakkauslistoihin.

Asennusvaiheessa tunnuksen avulla voidaan varmistaa oikean laitteen asennus oikeaan

paikkaan, mikä vähentää inhimillisten virheiden mahdollisuutta. Myös laitoksen ylläpi-

dossa tunnus helpottaa oikean laitteen löytymistä. Nykyisin tunnus leimataan usein lait-

teeseen tekstin ja numeroiden lisäksi viivakoodina tai QR-koodina, jolloin se on helppo

lukea digitaaliseen muotoon ja verrata sitä esimerkiksi tietokantaan, laitteen parametrei-

hin tai sähköiseen työmääräimeen. Eräs massavirtausmittaus eri vaiheissa on esitetty ku-

vassa 1, jossa on ympyröity laitteen tunnus.

11

KUVA 1. Laite PI-kaaviossa, säätökaaviossa, asennettuna ja instrumenttilistassa

Kuvasta 1 huomataan myös, että laitteen KKS-tunnus näyttää erilaiselta PI-kaaviossa ja

säätökaaviossa. PI-kaaviossa esitetty tunnus yksilöi säätöpiirin ja säätökaaviossa näkyvä

tunnus ”-U01” kertoo, että kyseessä on lähetin.

3.3 Tunnuksen rakenne

KKS-tunnus koostuu eri osista, joiden rakenne ja sisältö on ennalta määritelty ohjeessa.

Tunnuksen käyttökohteesta riippuen eri osat saavat hieman eri merkityksen.

3.3.1 Tunnusten tyypit

Tunnuksia on kolmea eri tyyppiä:

- prosessiin liittyvä tunnus

- asennuspistetunnus

- paikkatunnus. (KKS- Identification System for Power Stations 2004, 6.)

Prosessiin liittyvä tunnus on tarkoitettu erityisesti laitteiden ja instrumenttien yksilöintiin.

Asennuspistetunnus yksilöi laitteiden asennuspaikkoja, kuten sähkökaappeja, ohjauspa-

neeleja ja konsoleita. Paikkatunnuksella voidaan yksilöidä paikkoja rakennusten sisällä,

eri kerroksissa tai huoneissa, palosuoja-alueita tai topologiasia alueita. (KKS- Identifica-

tion System for Power Stations VGB-B 106A E 2004, 6.)

12

Tässä työssä tärkein näistä kolmesta tyypistä on ensimmäinen eli prosessiin liittyvät tun-

nukset, sillä ne ovat käytössä voimalaitoksen sähköistys- ja instrumentointisuunnitte-

lussa.

3.3.2 Tunnuksen erittelytasot

KKS-tunnus jaetaan neljään erittelytasoon, joista jokainen yksilöi laitteen edellistä tar-

kemmalla tasolla. Alun perin tasot perustuivat ainoastaan prosessiin liittyviin tunnuksiin,

mutta myöhemmin ne otettiin käyttöön myös muilla tunnustyypeillä. Tasot ja niiden se-

litykset on esitetty taulukossa 1. (KKS- Identification System for Power Stations VGB-B

106A E 2004, 6, 18.)

TAULUKKO 1. KKS-tunnuksen tasot prosessiin liittyville tunnuksille

Taso 0 1 2 3

Otsikko LAITOS TOIMINTO LAITEYKSIKKÖ/

SÄÄTÖPIIRI

LAITE/

SIGNAALI

Nimitys G F1 F2 F3 FN A1 A2 AN A3 B1 B2 BN

Sisältö A tai 1 A B C 1 2 A B 1 2 3 (A) A B 1 2

Taso 0

Laitoksen koodi, joka voi olla joko kirjaimia tai numeroita (kuva 2) (KKS- Identification

System for Power Stations VGB-B 106A E 2004, 20).

KUVA 2. Taso 0

Taso 1

Toiminnon koodi, joka kertoo mihin järjestelmään kyseinen tunnus kuuluu. Koodissa on

aina kolme kirjainta ja kaksi numeroa (kuva 3).

13

KUVA 3. Taso 1

Tason 1 ensimmäinen kirjain F1 kertoo pääryhmän, esimerkiksi polttoaineen syöttö, ve-

den, höyryn ja kaasun syöttö tai avustava järjestelmä. Toinen kirjain F2 ja kolmas kirjain

F3 tarkentavat järjestelmän osaa, esimerkiksi syöttöveden pumppaus tai siihen liittyvä

putkisto. Kaikkien järjestelmien koodit on määritetty KKS-ohjeessa. Numerointi FN ker-

too, mikä kyseisen järjestelmän osa on kyseessä (kuva 4).

KUVA 4. Järjestelmän dekadinen numerointi

Järjestelmien osien numerointi voidaan toteuttaa peräkkäisellä numeroinnilla tai dekadi-

sella numeroinnilla. Peräkkäisessä numeroinnissa järjestelmän jokainen haara saa juok-

sevan numeron väliltä 00 … 99. Tämä numerointitapa on suoraviivainen ja helppo ym-

märtää, mutta ei anna juurikaan joustovaraa tulevaisuutta ajatellen, sillä olemassa olevien

linjojen väliin ei voida lisätä uusia numeroita ilman koko lopun numerosekvenssin korot-

tamista tarvittavalla määrällä. Sen sijaan dekadinen numerointi, kuten kuvasta 4 huoma-

taan, mahdollistaa uusien haarojen lisäämisen helposti. Tämä numerointi perustuu siihen,

että aina järjestelmän osan vaihtuessa numerointia korotetaan kymmenellä, ja kaikki vä-

liin jäävät numerot ovat käytettävissä haaroitukseen. Numeroinnin suunta riippuu aineen

virtauksen suunnasta. (KKS- Identification System for Power Stations VGB-B 106B1 E,

8–23.)

14

Taso 2

Laiteyksikön tai säätöpiirin koodi, joka kertoo tarkemmin, mikä laitekokonaisuus tai piiri

on kyseessä (kuva 5).

KUVA 5. Taso 2

Tämä voi tarkoittaa esimerkiksi venttiilin ja toimilaitteen muodostamaa kokonaisuutta tai

mittauspiiriä, joka sisältää vaikkapa paine- tai lämpötilamittauksen. Koodi muodostuu

kahdesta kirjaimesta ja kolmesta numerosta. Ensimmäinen kirjain A1 kertoo laitteen tai

säätöpiirin tyypin seuraavalla tavalla:

- A = mekaaninen laite

- B = mekaaninen laite

- C = suora mittauspiiri

- D = suljettu säätöpiiri

- F = epäsuora mittauspiiri

- H = raskaan laitteen rakenneryhmä

- J = radioaktiivinen kokoonpano.

Tason 2 numerointi on juokseva ja sen suunta riippuu aineen virtauksen suunnasta. Tau-

lukossa 1 suluissa oleva kirjain A3 on valinnainen. Sillä voidaan erotella toisistaan piirissä

olevat säätöventtiilit, useat sähkökuorman tuottajat ja säätöpiirit, jotka sisältävät esimer-

kiksi useita säätimiä. (KKS- Identification System for Power Stations VGB-B 106B1 E,

42–45, 55.)

Taso 3

Viimeinen taso yksilöi suurimmalla tarkkuudella kyseessä olevan tunnuksen. Koodissa

on aina kaksi kirjainta, tai yksi muu merkki ja kirjain, ja kaksi numeroa (kuva 6).

KUVA 6. Taso 3

15

Jos kyseessä on esimerkiksi venttiilikokonaisuus, voidaan tällä koodilla yksilöidä vent-

tiilin toimilaite tai mittauspiirin tapauksessa mitta-anturiin liitetty lähetin. Jos kolmannen

tason koodin ensimmäinen kirjain B1 on X, Y tai Z, on kyseessä signaalitunnus. (KKS-

Identification System for Power Stations VGB-B 106B1 E, 58–59.)

3.4 Signaalitunnukset

Signaalitunnuksella tarkoitetaan koodia, joka voidaan lisätä KKS-tunnuksen tasolle 3.

Tällöin signaalitunnus korvaa komponentin yksilöivän tunnuksen. (KKS- Identification

System for Power Stations VGB-B 106B4 E 2004, 56.) Signaalitunnuksella ilmaistaan,

minkä tyyppinen signaali on kyseessä. KKS-ohjeissa on annettu ehdotuksia signaalitun-

nusten kirjainten ja numeroiden valintaan, mutta käytännössä tunnukset valitaan aina pro-

jektikohtaisesti ja ohje niitä varten saadaan tavallisesti asiakkaalta. Tästä johtuen signaa-

litunnusjärjestelmät voivat projektien välillä poiketa paljonkin toisistaan.

Signaalitunnus koostuu aina neljästä merkistä, joista kaksi ensimmäistä ovat kirjaimia ja

kaksi viimeistä numeroita. Rakenne on siis sama, kuin kaikissa muissakin prosessiin liit-

tyvän tunnuksen tason 3 rakenteissa, kuten taulukosta 2 huomataan.

TAULUKKO 2. Signaalitunnuksen rakenne

TUNNUKSEN TASO 3

X, Y tai Z A-Z 00-99

Signaalin suunta Signaalin/toiminnan alue Signaalin numero

Signaalin suunnan kertovien kirjainten merkitykset ovat seuraavat:

- X: lähdesignaali, kuten käyntitieto moottorilta

- Y: kohdesignaali, kuten venttiilin avauskäsky

- Z: epäsuora lähdesignaali. (KKS- Identification System for Power Stations VGB-

B 106B4 E 2004, 56.)

Ensimmäinen kirjain on siis aina jokin näistä, yleensä X tai Y. Kirjainta Z käytetään erit-

täin harvoin eikä tässä työssä yhdenmukaisuuden ja selkeyden vuoksi laisinkaan. Seu-

16

raava kirjain, joka osoittaa signaalin tai toiminnan alueen on määritettävä projektikohtai-

sesti. Suunnittelija saa päättää kirjaimen lähes vapaasti, mutta yleensä noudatetaan tiettyjä

hyväksi havaittuja merkintöjä. Rajoituksena on, että toinen kirjain ei saa olla X tai Y, sillä

ne on varattu tulevaisuudessa mahdollisesti tehtäville standardisoinnin määrityksille.

(KKS- Identification System for Power Stations VGB-B 106B4 E 2004, 57.)

3.5 Esimerkkejä Valmetin tunnuksista

Seuraavaksi on esitetty kaksi esimerkkiä, miten tunnuksia on käytetty Valmetin laitos-

suunnittelussa KKS-koodeja käyttävän projektin yhteydessä. Kuvassa 7 esiintyvien tun-

nusten rakenne on avattu kohta kohdalta.

KUVA 7. Moottori ja virtaussuutin

Kuvassa 7 vasemmalla olevan moottorin tunnus on 4LAC10AP001-M01. Ensimmäinen

numero kertoo, että moottori kuuluu laitoskokonaisuuden rakennukseen 4. LAC

tarkoittaa syöttöveden pumppausjärjestelmää. Luku 10 viittaa syöttövesipumppuun 1.

Seuraava A tarkoittaa mekaanista laitetta ja P pumppua. Seuraavana oleva merkki ”-”

tarkoittaa sähköistä komponenttia ja M01 kertoo, että kyseessä on moottori.

Kuvassa 7 oikealla olevan virtaussuuttimen tunnus on 4LBA20CF001QB01.

Ensimmäinen numero kertoo, että suutin kuuluu laitoskokonaisuuden rakennukseen 4.

LBA viittaa päähöyryn putkistojärjestelmään. Luku 20 tarkoittaa päähöyryyn liittyvää

komponenttia. CF001 ilmaisee, että kyseessä on ensimmäinen virtausmittauspiiri

kyseisessä putkessa. QB tarkoittaa ei-sähköistä mittausinstrumenttia eli tässä

virtaussuutinta.

17

3.6 Signaalien käyttö Valmetin laitossuunnittelussa

Signaalien oikeanlaiset tunnukset ovat erittäin tärkeitä suunnittelun ja käytön sujuvuuden

takaamiseksi. Tästä syystä jokaisen KKS-projektin yhteydessä suunnittelija on joutunut

lisäämään tunnuksen käsin. Comoksen mallikannan päivityksellä pyritään yksinkertais-

tamaan ja nopeuttamaan työtä, jotta suunnittelijoiden ei tarvitse toistaa samoja työvaiheita

jokaisessa projektissa.

Comoksen käytön alkuvaiheissa suunnittelussa ei ymmärrettävästi voitu ottaa huomioon

kaikkia seikkoja, jotka myöhemmin vaikuttivat työn sujuvuuteen. Vanhan toimintatavan

mukaisesti toteutettuna kuvien välillä siirretty tieto merkittiin numeroiduilla ympyröillä

(kuva 8).

KUVA 8. Signaalin siirto kuvasta toiseen vanhalla tavalla

Tällainen tapa soveltuu, kun signaalien siirtoja on pienempi määrä eikä sekaannuksen

vaaraa ole. Signaalin siirron viereen on aina merkitty selvästi kohde- ja lähdesivun nu-

mero ja selittävä teksti, josta käy ilmi signaalin sisältö. Signaalista ei kuitenkaan käy ilmi,

mistä järjestelmästä ja piiristä signaali on lähtöisin ja ainoa yksilöivä tekijä on suunnitte-

lijan itse kirjoittama teksti.

Myöhemmin suunnittelussa otettiin käyttöön uusi tapa tehdä signaalien siirtoja. Nume-

rolliset ympyrät korvattiin nuolilla, joista pystyy heti näkemään signaalin laadun, järjes-

telmän ja piirin kuvauksen sekä kohde- ja lähdesivun (kuva 9).

18

KUVA 9. Signaalin siirto uudella tavalla KKS-projekteissa

Nuolet otettiin käyttöön vanhan tavan ohessa yksittäisten henkilöiden toimesta eikä nii-

den käyttöä missään vaiheessa yhdenmukaistettu. Tästä johtuen signaalin selitteen for-

maatti saattaa vaihdella huomattavasti eri projektien ja suunnittelijoiden välillä eikä se

siksi ole riittävän luotettavasti yksilöivä. Myöskään piirin tunnuskoodi ei ole aina saman

tyylin mukainen, sillä KKS-tunnus on käytössä ainoastaan KKS-projekteissa. Muissa

projekteissa käytetään projektikohtaisia tunnuksia, jotka ovat hankalasti tulkittavissa,

sillä ne eivät seuraa mitään standardia ja numerointi on monesti täysin juokseva järjestel-

mästä riippumatta (kuva 10).

KUVA 10. Signaalin siirto ilman KKS-tunnusta

3.7 Signaalitunnusten käyttö

Signaalien siirtojen yksilöimiseksi KKS-tunnuksen perään lisätään signaalitunnus, jolloin

nuolesta on heti luettavissa yksiselitteisesti signaalin tyyppi. Nykyisin suunnittelija lisää

kaikki signaalitunnukset käsin ilman yhdenmukaista tapaa. Monesti asiakas antaa ohjeen,

jossa on kerrottu yleisimpien signaalien tunnukset, mutta nämä ohjeet ovat lähes aina

ristiriidassa keskenään, sillä varsinainen VGB:n KKS-ohje ei ota kantaa yksittäisten sig-

naalien tunnuksiin. Tapauksissa, joissa asiakas ei anna ohjetta, suunnittelijan on mukail-

tava jonkin aiemman projektin tunnuksia, jolloin vanhat virheet saattavat siirtyä uuteen

projektiin. Tunnusten lisääminen on työlästä, joten toisinaan suunnittelijat pyrkivät oiko-

maan työssä. Tällöin tunnuksia ei tule mietittyä johdonmukaisesti ja lopputulos on se-

kava.

Signaalin selite

KKS-tunnus

Piirin nimi

Kohdesivut

19

4 ERILAISET JÄRJESTELMÄFILOSOFIAT

Yrityksen käyttämä tietojärjestelmä voidaan toteuttaa useilla eri tavoilla. Perinteisin tapa

on tallentaa tietoa fyysisesti paperille. Digitaalinen tallennus on kuitenkin korvannut tä-

män tavan lähes kokonaan, jolloin saavutetaan varma ja helposti käytettävä järjestelmä.

Digitaalisen tietojärjestelmän toteutukseen löytyy monia tapoja.

4.1 Dokumenttipohjainen sovellus

Dokumenttipohjainen ajattelutapa on tietokantoja tuntemattomalle kaikkein tutuin ja yk-

sinkertaisin tapa suunnitteluun ja tiedon tallennukseen. Suunnittelutyössä on varsinkin

aiemmin käytetty paljon CAD-ohjelmia, joissa jokainen kuva on piirrettävä käsin. Suun-

nittelun apuna käytetään monesti symbolikirjastoja, joista usein käytetyt symbolin ja mer-

kit on helppo kopioida kuvaan. Tehokas tapa luoda uusia projekteja on myös kopioida

olemassa olevat kuvat jostakin vanhasta projektista, mutta tällöin on riski samalla kopi-

oida myös virheellisiä kuvia. Ongelmana on myös tiedon siirto suunnittelijan ja doku-

menttien tallennuspaikan välillä, sillä kuvaan tehtävät muutokset eivät päivity automaat-

tisesti muihin kuviin ja jokainen kuva on muokattava erikseen käsin. Tämä aiheuttaa hel-

posti sekaannuksia. (Nissinen 2007, 15–16; Virtanen 2008, 21–22.)

4.2 Tietokantapohjainen sovellus

Tietokantoihin perustuvat sovellukset ovat nykyään todella yleisiä. Tietokanta voidaan

ajatella joukoksi toiminnallista dataa, jota käytössä olevat ohjelmistot hyödyntävät. Ylei-

sin tietokantatyyppi on relaatiotietokanta, jossa tiedot on tallennettu taulukoihin, joiden

solujen välille muodostetaan yhteyksiä. Näin tietokannasta saadaan yhtenäinen koko-

naisuus ja tiedon tallentaminen ja löytämine on helppoa. (Nissinen 2007, 15–16; Virtanen

2008, 21–22.)

20

4.3 Oliopohjainen sovellus

Oliopohjaisen järjestelmän tavoitteena on luoda tietokantaan kokonaisvaltainen kuvaus

todellisesta laitteesta tai muusta prosessin osasta. Olio on järjestelmän perusyksikkö, joka

kootaan erilaisista attribuuteista ja toiminnallisuuksista halutun mukaiseksi. Monissa jär-

jestelmissä oliota kutsutaan objektiksi. Objekti sisältää kaikki tarvittavat graafiset ja aak-

kosnumeeriset tiedot. Laitosta suunniteltaessa objektit linkitetään projektiin, jolloin ob-

jektin ominaisuudet siirtyvät kyseiseen projektiin ja graafinen ulkoasu tulee näkyviin ku-

viin. Objekti ei kuitenkaan varsinaisesti kopioidu projektiin, vaan projekti vain käyttää

tietokannassa olevan perusobjektin tietoja. (Nissinen 2007, 15–16; Virtanen 2008, 21–

22.)

21

5 COMOS

Comos on alun perin vuonna 1991 Innotec GmbH:n kehittämä olio- eli objektipohjainen

suunnitteluohjelmisto, jota nykyään ylläpitää Siemens AG:n tytäryhtiö Comos Industry

Solutions GmbH (Bloomberg 2018). Valmetilla on tällä hetkellä käytössä versio Comos

10.1.

Comos perustuu oliopohjaiseen toimintaan, joka mahdollistaa tiedon kaksisuuntaisen siir-

tymisen. Comoksessa olioita kutsutaan objekteiksi, jotka pitävät sisällään tietyn infor-

maation objektin toiminnasta.

Comos tarjoaa laitoksien suunnittelijoille, toiminnanharjoittajille, yritysten johdolle ja

yhteistyökumppaneille yhtenäisen ratkaisun suunnitteluun ja tiedonhallintaan projektien

eri vaiheissa. Ohjelmiston tarkoituksena on helpottaa suunnittelua ja operointia yhdistä-

mällä laitokseen liittyvä informaatio keskitetysti yhteen tietojärjestelmään, joka on jokai-

sen osapuolen saatavilla laitoksen koko elinkaaren ajan. (Plant engineering software

2018.) Tässä työssä keskitytään ohjelmiston hyödyntämiseen suunnitteluvaiheessa ja

ominaisuuksiin, jotka liittyvät KKS-tunnusten määrittelyyn ja syöttämiseen tietokantaan.

Comos-ohjelmistopaketti koostuu tuoteryhmistä ja moduuleista, joista yritys voi kasata

sopivan kokonaisuuden (kuvio 1). Moduulit toimivat keskenään yhteistyössä tietokannan

kautta, jolloin kaikki projektiin tehdyt muutokset ovat kaikkien saatavilla. (Plant engi-

neering software 2018.)

KUVIO 1. Comoksen tuoteryhmärakenne (COMOS at a glance 2018)

COMOS Platform

Enterprise Server

Process Automation Operations Lifecycle

22

Comos Platform on tehokas ohjelmistoalusta, joka mahdollistaa laitoksen koko elinkaa-

ren hallinnan. Siihen sisältyy työkaluja esimerkiksi suunnitteluun, ylläpitoon ja huoltoon.

Alustaan kuuluu myös Enterprise Server, jonka avulla kaikki laitokseen liittyvät tiedot

ovat helposti saatavilla keskitetysti. View Stationin avulla projektia voidaan tarkastella

ilman muokkausoikeuksia, jolloin varsinaista suunnitteluohjelmaa ei tarvitse avata. Tällä

tavoin voidaan toimia pienemmällä määrällä lisenssejä, sillä View Station -ikkunoita voi

olla avoimena useampia samaan aikaan. (Plant engineering software 2018.)

Process-tuoteryhmä sisältää työkaluja projektin alun suunnitteluun, josta käytetään eng-

lanninkielistä termiä ”front-end engineering”. Tämä vaihe sisältää prosessin eri vaiheiden

järjestelyä ja suurpiirteistä kustannusten ja prossin ominaisuuksien laskentaa. Seuraa-

vassa vaiheessa siirrytään prosessin PI-kaavion laatimiseen. PI-kaaviota piirrettäessä voi-

daan luoda prosessin osille objekteja, joita käytetään myöhemmin suunnittelussa. PI-

kaavio toimii pohjana myöhemmälle sähköistykselle ja instrumentoinnille. (Plant en-

gineering software 2018.)

Automation-tuoteryhmän työkaluilla voidaan toteuttaa projektin toiminnallista suunnitte-

lua, esimerkiksi säätö- lukitus- ja sekvenssikaavioita, joista käy ilmi laitoksen prosessien

toiminta ja eri osioiden vaikutus toisiinsa. (Plant engineering software 2018.)

Operations-tuoteryhmä tarjoaa mahdollisuuden monipuoliselle laitoksen ylläpidolle.

Suunnittelussa tuotettu tieto saadaan tällä tavoin ylläpitohenkilöstön ja operaattorien käy-

tettäväksi. Laitoksen käytössä ja huollossa tuotettu informaatio varastoidaan samaan tie-

tokantaan kaiken muun tiedon kanssa erilaisten rajapintojen kautta ja Lifecycle-tuoteryh-

män kanssa yhteistyössä saavutetaan informaation varastoinnista ja käytöstä mahdolli-

simman suuri hyöty. Tarjolla on myös mobiilisovelluksia, jotka mahdollistavat tietojen

tutkimisen ja muokkaamisen paikasta riippumatta. (Plant engineering software 2018.)

5.1 Visual Basic -skriptit

Comoksen tehokas käyttö vaatii käyttäjältä Visual Basic Scripting Edition (VBScript)

-ohjelmointikielen perusasioiden hallitsemisen, sillä ohjelman monet ominaisuudet pe-

rustuvat lyhyehköihin ohjelmapätkiin eli skripteihin, jotka on kirjoitettu tällä kielellä.

23

Skriptejä käytetään esimerkiksi Base-objektien attribuuttien muokkaamiseen ja kyselyjen

luomiseen. (Microsoft 2018). Näistä kerrotaan tarkemmin myöhemmissä kappaleissa.

VBScript on osa Microsoftin Visual Basic -ohjelmointikieliperhettä. Se on kehitetty ni-

menomaan ohjelmien sisäisten skriptien kirjoittamiseen. Kehityksessä on otettu huomi-

oon ohjelmoinnin helppous ja matala aloituskynnys tekemällä kielen syntaksista eli kie-

liopista yksinkertainen ja helppolukuinen. (Microsoft 2018).

5.2 Ohjelmiston rakenne ja käyttö Valmetilla

Comos-suunnitteluohjelmiston avautuessa näkyviin tulee vakioikkuna, jonka vasem-

massa laidassa sijaitsee projektin puurakenne ja objektien yksityiskohtaisia tietoja ja oi-

keassa laidassa kuvaikkuna (kuva 11).

KUVA 11. Comoksen suunnitteluikkuna

Vasemman laidan puurakenteesta löytyy jokaisen projektin osan itsenäinen rakenne, joka

sisältää tarvittavat objektit (kuva 12).

24

KUVA 12. Puurakenne

Comoksen rakenne perustuu objektien hierarkiaan. Koko projekti on jaoteltu osakokonai-

suuksiin (Unit), jotka jakautuvat edelleen pienempiin yksiköihin ja lopulta yksittäisiin

objekteihin. Puurakenteessa laitoksen eri järjestelmät ja osat on lajiteltu toistensa alle.

Instrumenttipiirin tyyppi (esim. PI, FI, FIC, HS) määräytyy sen mukaan, minkä tyyppisiä

funktioita sen alle on luotu. (Tiikko 2015, 25).

Unit-kansion alla olevat alikansiot on nimetty havainnollistavasti sisältönsä mukaan.

Tässä työssä käsitellyt KKS-signaalitunnukset koskevat enimmäkseen Instruments and

controls- ja Equipment-kansioiden sisältöä. Instruments and controls -kansiossa sijaitse-

vien piiriobjektien alla sijaitsevat funktiot eli suunnittelijoiden puhekielessä ”tikkarit”.

Equipment-kansiossa sijaitsee laitteet, kuten pumput ja säiliöt.

Funktioita eli tikkareita voi olla seuraavan tyyppisiä:

- Remote indication: mittausfunktio, joka sisältää mittausyhteen, lähettimen, luki-

tusrajoja, väyläsiirto-objekteja ja signaaliobjekteja. Mittausfunktion alla voi olla

vain yksi fyysinen mittaus, mutta funktio voi olla myös laskennallinen, jolloin se

ei sisällä lainkaan mittalaitetta. Kuvion 12 esimerkissä on juuri tällainen funktio.

- Control function: säätöfunktio, joka sisältää säätötoimilaitteen, kuten säätövent-

tiilin tai säätöpellin ja näihin kohdistuvia lukituksia ja käsiasemia.

25

- Controller function: säädinfunktio, joka sisältää säätimeen liittyviä objekteja, ku-

ten operaattorinäyttöjä, Local/Remote-valitsimia ja asetusarvoja.

- Switch remote: kytkinmittausfunktio, joka sisältää rajaobjekteja, kuten pintakyt-

kimiä.

- Switching function: kytkinohjausfunktio, joka sisältää kytkettäviä laitteita, kuten

ON/OFF-venttiilejä ja niihin liittyviä objekteja, kuten auki- ja kiinni-rajoja.

- Software function: Laskennallinen funktio, jota käytetään laskennallisissa toimin-

noissa, joissa funktioon ei liity varsinaista fyysistä laitetta. Laskennallista funk-

tiota käytetään esimerkiksi yksittäisten operaattorin valintaobjektien kanssa. (Ku-

ningas 2011, 10–16).

Comoksessa jokaisella objektilla on yksilöivä positio, joka estää saman objektin esiinty-

misen useaan kertaan saman projektin sisällä. KKS-projektissa positiot annetaan funkti-

oille ja muissa projekteissa suoraa piirille. Objekteja on useita eri tyyppejä:

- Base-objekti, joka toimii pohjana muille objekteille

- Engineering-objekti, joka pohjautuu Base-objektiin

- Attribuutti, joka on objekti Base-objektin tai Engineering-objektin sisällä. Attri-

buutti varastoi isäntäobjektin tietoja

- Laiteobjekti, kuten moottori, pumppu, tankki ja anturi

Koska tietokantarakenteessa objektit ja kuvat on linkitetty toisiinsa, pystyy käyttäjä navi-

goimaan helposti kuvasta puurakenteen siihen paikkaan, jossa objekti sijaitsee (kuva 13).

Navigointi nopeuttaa huomattavasti tietokannan sisällä liikkumista, sillä piirejä ja objek-

teja ei tarvitse etsiä käsin.

KUVA 13. Navigointi puurakenteeseen

26

5.2.1 Base-objektit ja standarditaulut

Projektin jokainen objekti perustuu Base-objektiin. Projektin paikallinen Base-objekti on

suora kopio mallitietokannan Base-objektista. Base-objekti määrittää kaikki objektin

ominaisuudet:

- Mitä attribuutteja objektilla on eli mitä tietoja käyttäjä voi syöttää objektille

- Millaisia objekteja voidaan luoda kyseisen objektin alle, esimerkiksi lähettimen

alle I/O-objekti tai moottorin alle taajuusmuuttaja

- Objektin esitystapa eri piirustuksissa

Objektien esitystavat vaihtelevat riippuen siitä, esitetäänkö ne säätö-, lukitus- vai PI-

kaaviossa. Graafista esitystä kuvaavaa skriptiä ei ole varsinaisesti tallennettu Base-objek-

tiin, vaan keskitetysti standarditauluun, johon Base-objektin ominaisuuksissa on viittaus.

Standarditaulut ovat eräänlaisia taulukoita, joihin on tallennettu Base-objektien tarvitse-

mia tietoja. Tällöin standarditaulun tietoja tai skriptiä muokkaamalla muutokset periyty-

vät Base-objektille.

Standarditauluja voidaan projektin aikana kopioida paikalliseksi kyseiseen projektiin tai

ne voidaan jättää kopioimatta, jolloin projektissa oleva objekti hakee tiedot suoraa malli-

tietokannassa sijaitsevasta standarditaulusta. Standarditaulut olisi suositeltavaa kopioida

paikallisiksi, mikä helpottaa mallikannan ylläpitoa, sillä tällöin muutokset eivät pääse pe-

riytymään epätoivottuihin kohteisiin.

5.2.2 Objektien attribuutit

Objektin attribuutteja päästään muokkaamaan valitsemalla objekti joko puurakenteesta

tai kuvasta ja avaamalla Properties- eli asetusikkuna. Eri tyyppisten objektien asetusik-

kunoiden valikot poikkeavat hieman toisistaan, mutta yleisesti ne ovat kokoelmia objek-

tien attribuuteista, joita käyttäjä voi muokata. Nämä attribuutit liittyvät useimmiten lait-

teiden teknisiin tietoihin, objektin ominaisuuksiin, kuten positiointiin, signaaliobjektien

ominaisuuksiin ja objektien graafiseen ulkoasuun.

27

Projektissa olevien objektien kaikki ominaisuudet on peilattu suoraa Base-objektilta eli

ne ovat identtiset Base-objektin ominaisuuksien kanssa. Kun uusi objekti luodaan projek-

tiin, se hakee tiedot automaattisesti Base-objektilta.

Kuviossa 2 esitetään objektien, attribuuttien ja standarditaulujen suhde toisiinsa. Attri-

buutteja tarkasteltaessa huomataan, että ylimmällä tasolla sijaitsee ns. attribuuttikatalogi.

Tämän katalogiin on luotu kaikki objektien käyttämät attribuutit, jolloin ne voidaan va-

rastoida ja niitä voidaan muokata keskitetysti yhdessä paikassa.

Kuviossa 2 on otettu esimerkiksi objektin graafisen ulkoasun määrittelevä attribuutti

S019, johon on jo tällä ylimmällä tasolla linkitetty standarditaulu, joka sisältää symbolien

grafiikkaskriptit. Attribuutti ja standarditaulun linkitys periytyvät Base-objektin puura-

kenteelle. Varsinainen Base-objekti on tämän rakenteen alimmalla tasolla sijaitseva Indi-

cation-objekti. Varsinaisen Base-objektin tasolla attribuuttiin on määritelty symbo-

liskripti, joka kertoo objektille, mistä attribuutista ulkoasu haetaan. Tässä tapauksessa att-

ribuutti on juuri aiemmin linkitetty S019. Attribuutin asetuksista määritellään, mitä stan-

darditaulun skriptiä sen tulee käyttää grafiikan esittämiseen.

28

KUVIO 2. Attribuutin periytyminen ja tiedon linkittäminen

1)

2)

1) Symboliskripti kertoo objektille, mistä attribuutista ulkoasu haetaan 2) Attribuutin asetuksista valitaan, mitä taulun arvoa halutaan käyttää, eli mitä grafiikkaskriptiä käytetään

29

5.3 Työskentelytasot

Comoksessa työskennellään monesti työskentelytasoilla. Tasot ovat alkuperäisen projek-

tin ”päälle” luotuja näkymiä, jotka mahdollistavat käyttäjien työskentelyn rinnakkain il-

man, että tehdyt muutokset vaikuttavat alkuperäiseen projektiin. Työskentelytasojen tar-

koitus on:

- Helpottaa hajautettua työskentelyä projekteissa

- Mahdollistaa projektin osien turvallisen ulkoistuksen yhteistyökumppaneille

- Suojata projektia virheellisiltä muutoksilta

- Helpottaa historiatietojen hallintaa (COMOS Platform Operation. Operating

Manual 2013, 22–23).

Tasoja voidaan pitää läpinäkyvinä kerroksina, joille alkuperäisen projektin objektit hei-

jastuvat (kuvio 3). Kun objektia muokataan tason päällä, se ei vaikuta alkuperäiseen pro-

jektiin, mutta jos tämä tason päälle luodaan ylempi taso, näkyvät alemman tason muutok-

set sillä. Tasojen päällä objekteja voidaan luoda, muokata ja poistaa vapaasti. (COMOS

Platform Operation. Operating Manual 2013, 23).

KUVIO 3. Työskentelytasot

Kun halutut muutokset tasolla on tehty, voidaan taso pudottaa eli yhdistää alla olevaan

projektiin. Tätä varten Comoksessa on käytössä erityinen vapautusprosessi. Vapautus-

prosessissa tavallaan toistetaan tason päällä tehdyt operaatiot alkuperäiseen projektiin.

Alkuperäinen projekti

Taso 2

Taso 1

30

Tasoilla työskennellessä olisi tärkeää muistaa yhdistää tasot riittävän usein, jotta työsken-

telyn aikana projektiin tehdyt muutokset eivät aiheuta konflikteja tietojen välillä.

(COMOS Platform Operation. Operating Manual 2013, 24).

5.4 Kyselyt

Kysely (eng. Query) on Comoksen perustyökalu, joka mahdollistaa objektien käsittelyn

nopeasti ja tehokkaasti. Kyselyn avulla voidaan etsiä objekteja halutulta alueelta tietyillä

kriteereillä ja muokata niitä tehokkaasti suurissa erissä.

Kyselyn tuloksena saadaan taulukko, jonka sarakkeita voidaan muokata halutuiksi sen

mukaan, mitä tietoja halutaan nähdä tai mitä attribuutteja halutaan muokata (kuva 14).

KUVA 14. Kysely

Kuvan 14 kyselyä käytettiin objektien positioiden ja signaalitunnusten esitystavan muok-

kaamiseen. Oikean laidan FullLabel-sarake näyttää objektin koko tunnuksen. Show sig-

nal tag -sarakkeen valintaruuduilla voidaan määrittää signaalitunnuksen näkyminen ku-

vissa. Show position in diagram -sarakkeella voidaan tehdä sama objektin positiolle. Lo-

put sarakkeet antavat tietoa objektista, kuten selkokielisen kuvauksen, signaalitunnuksen

ja listan kuvista, joissa kyseinen objekti sijaitsee.

31

5.5 Mallikanta

Valmet on kehittänyt suunnittelun avuksi mallitietokannan, johon on luotu mallikuvat eri

kattilatyyppien säätö-, lukitus-, sekvenssi- ja PI-kaavioista sekä tarvittavat selostukset ja

luettelot. Mallikanta on eräänlainen suuri projekti, jonka pohjalta voidaan tehdä yksittäi-

siä projekteja. Projektin aloitusvaihe voidaan yleensä tehdä kahdella eri tavalla; tarvitta-

vat kuvat ja kansiot kopioidaan joko jo olemassa olevasta projektista tai mallikannasta.

Oikea periaate on kopioida projekti mallikannasta. Olemassa olevasta projektista kopioi-

dessa vanhat virheet saattavat siirtyä uuteen projektiin. Kun kuvat avataan kopioinnin

jälkeen uudessa projektissa, voidaan valita, halutaanko Comoksen sijoittavan objektit ku-

viin automaattisesti, vai kopioivan objektien kansiorakenteen kuvan alle puurakentee-

seen. Monesti Comos pystyy automaattisesti sijoittamaan objektit, mutta suurimmassa

osassa tapauksista suunnittelijan on sijoitettava ne käsin.

Mallikantaa on päivitetty Comoksen käytön historian aikana jatkuvasti eri henkilöiden

toimesta, joten tällä hetkellä sen on kokonaisuutena sekava. Tästä syystä mallikannasta

kopioitavat kuvat eivät toimi aina kuten on tarkoitettu ja kuvien korjaamiseksi on tehtävä

paljon työtä projektikohtaisesti.

32

6 TUNNUSJÄRJESTELMÄN LUOMINEN

Työn varsinainen tarkoitus oli luoda uusi tunnusjärjestelmä laitossuunnittelua varten. Uu-

den tunnusjärjestelmän luominen toteutettiin kahtena kokonaisuutena; lista signaalitun-

nuksista ja ohje tunnusten käyttöön.

6.1 Signaalitunnuslista

Työn ensimmäinen vaihe oli määritellä tarvittavat signaalitunnukset. Tunnuksista laadit-

tiin lista, josta käy ilmi tapauskohtaiset koodit (liite 1). Lista jaoteltiin signaalitunnuksen

toisen merkin mukaisesti aakkosjärjestykseen taulukon 3 mukaisesti.

TAULUKKO 3. Signaalitunnustyypit

2nd letter Analog / binary

A Automatic control, group control (sekvenssit) B

B Individual drive control (yksittäiset ohjaukset) B

C Control valve, actuator (säätöventtiilit ja toimilaitteet) B

D Signal transferred via bus (väylän läpi siirretyt signaalit) B

E F G Binary contact signal (rajakytkimet) B

H Binary limit signal derived from analog measurement signal B

J K Alternative for Z-numbers B

L Alternative for N-numbers B

M Individual and common alarms (yleiset hälytykset) B

N Operator selection signal (operaattorin valinnat) B

P Q Analogue signal (analogiasignaalit) A

R Controller signal (säätimen signaalit) A/B

S Step signal of sequence control (sekvenssin askeelet) B

T U Logical/Gated signal (logiikkasignaalit) B

V Alternative for Z-numbers B

W X Y Z Safety related signal (turvajärjestelmän signaalit) B

33

Työhön kuului vapaasti määriteltävien signaalien tunnusten lisäksi väyläsignaalien, val-

vomonäyttöjen, valinta- ja operointinäyttöjen, tila- ja hälytysobjektien, rajakytkinsignaa-

lien ja analogisista mittauksista luotujen binääristen raja-arvo-objektien tunnukset. Va-

paasti määriteltävällä signaalilla tarkoitetaan signaalia, jota käytetään binäärisen tai ana-

logisen tiedon siirtoon kuvasta toiseen. Suunnittelija luo ja määrittelee nämä signaalit itse.

Osa tunnuksista oli aiemmin jo määritelty Comoksen mallikannan standarditauluissa,

mutta suurin osa oli jätetty vapaavalintaiseksi. Myös joitain standarditauluissa olevia sig-

naalitunnuksia jouduttiin hieman muuttamaan. Tunnusten valinnassa käytettiin apuna

vanhojen projektien tunnuksia, asiakkaiden antamia ohjeita ja VGB:n KKS-ohjeistusta.

Tunnusten valinnan haasteellisuutta lisäsi se, että aiemmat käytännöt olivat hyvin seka-

via.

Asiakkaiden antamat ohjeet aiempia projekteja varten koostuivat eri suunnittelutoimisto-

jen omista ohjeista, joita oli aikojen saatossa muokattu kullekin projektille ja asiakkaalle

sopivammaksi. Työssä apuna käytettyjä listoja kerättiin yhteensä 14:sta vanhasta KKS-

projektista, joskin jotkin näistä listoista olivat peräisin keskenään samoilta suunnittelutoi-

mistoilta. Listojen monipuolisuus oli hyödyksi, mutta toisaalta niihin oli kertynyt paljon

tunnuksia, joita ei käytännössä käytettäisi missään tulevissa projekteissa, tai joiden mer-

kitys oli mielekkäämpää jättää avoimeksi suunnittelijan valinnanvapauden lisäämiseksi.

Otettaessa mallia vanhoista projekteista oli huomioitava kyseisen projektin suunnitte-

luohjeen vaatimukset ja se, että suunnittelijat eivät aina olleet seuranneet ohjeita kovin-

kaan tarkasti. Usein projekteista löytyvät ohjeiden vastaiset tunnukset olivat kuitenkin

valittu jonkin vakiintuneen käytännön perusteella, jolloin niiden käyttöä jatkossakin oli

syytä harkita, jotta suunnittelijoiden olisi helpompi omaksua uudet ohjeet.

VGB:n antamassa KKS-ohjeessa VGB-B 106e ei määritellä yksittäisiä tunnuksia eikä

ohje muutenkaan ole velvoittava, vaan ainoastaan suositus. Ohjeessa on kuitenkin annettu

tunnusten ryhmittelystä esimerkki, jota oman ohjeen kasaamisessa mukailtiin. Seuraa-

vaksi on käsitelty yksitellen jokaisen ryhmän määrittelyssä esiin nousseen huomiot.

34

Ryhmä A: sekvenssiohjaukset

Ryhmään A kuuluvat sekvenssiohjeukseen liittyvät signaalit eli esimerkiksi sekvenssin

käyntilupa, aloituskomento ja tieto sekvenssin etenemisetä. Näistä signaaleista monet oli-

vat vakiintuneita ja suoraa standarditaulusta saatavilla. Pohdinnan kohteena oli se, lisä-

täänkö listaan signaalit vaihtosekvenssejä varten, mutta lopulta päätettiin yksikertaisuu-

den vuoksi jättää ne pois ja sisällyttää käynnistys- ja pysäytyssekvensseihin.

Ryhmä B: yksittäiset ohjaukset

Ryhmään B kuuluvat yksittäisten laitteiden, kuten moottorien, venttiilien ja nuohoimien

käyntiin, tilaan ja suojaukseen liittyvät signaalit. Monet näistäkin signaaleista olivat va-

kiintuneita. Tähän ryhmään haluttiin lisätä myös laitteiden fyysisesti langoitettujen tur-

vallisuuteen liittyvien signaalien tunnukset, joita ei oltu aiemmin määritetty standarditau-

luissa.

Ryhmä C: Säätöventtiilit ja toimilaitteet

Tähän ryhmään kuuluvat säätöventtiilien ja niihin liittyvien toimilaitteiden avaukseen,

sulkemiseen ja suojaukseen liittyvät signaalit. Myös tähän ryhmään lisättiin fyysisesti

langoitettujen signaalien tunnukset sekä tunnukset avaus- ja sulkemiskomentojen takai-

sinkytkentöjä varten.

Ryhmä D: Väylän läpi siirretyt signaalit

Väylän läpi siirrettävillä signaaleilla tarkoitetaan tiedon kulkua järjestelmästä toiseen, esi-

merkiksi turvajärjestelmästä (SIS) DCS:ään tai BMS:ään. Tämä ryhmä haluttiin käyttöön,

jotta signaalitunnuksesta voidaan heti huomata signaalin olevan peräisin toisesta järjes-

telmästä. Tunnukset suunniteltiin ryhmiteltäväksi kohdejärjestelmän mukaan ja sen mu-

kaan onko kyseessä analoginen vai binäärinen signaali. Tästä ryhmittelystä kuitenkin luo-

vuttiin, sillä tiettyjen numeroiden vakioiminen olisi estänyt tunnusten käytön kuvan 15

mukaisessa tilanteessa.

35

KUVA 15. Ryhmän D signaalin käyttö

Tästä syystä koko ryhmä vapautettiin vapaasti valittaviksi tunnuksiksi ja kaikki ryhmän

signaalit määritettiin binäärisiksi.

Ryhmä G: Rajakytkinsignaalit

Tässä ryhmässä olevat signaalit kertovat rajakytkimen tilan. Jokaiselle tilalle on määri-

tetty kiinteä tunnus kytkimen tilan ja muutoksen suunnan perusteella. Numeroilla on eri-

telty, onko kyseessä turvajärjestelmän signaali vai DCS-signaali.

Ryhmä H: analogiamittauksista johdetut binääriset signaalit

Ryhmän H numerointi on täysin vastaava, kuin ryhmän G. Siinä pätee samat signaalin

vertailuun ja suuntaan liittyvät seikat. Numeroinnissa on aiemmin käytetty ainakin kahta

erilaista tapaa, mutta teknisesti molemmat ovat yhtä päteviä.

Ryhmä M: yleiset hälytykset

Tähän ryhmään on kerätty lista yleisesti käytettyjä hälytyssignaaleja, joista monet liitty-

vät sähkön syöttöön ja sähköisiin kuormiin. Instrumentoinnin ja toiminnallisen suunnit-

telun kannalta tärkeämpiä ovat mittauksiin liittyvät hälytykset, joita ei aiemmissa ohjeis-

tuksissa oltu määritelty. Listaa täydennettiin käymällä läpi projekteissa esiintyviä mit-

tauksia ja niistä mahdollisesti aiheutuvia hälytyksiä.

Ryhmä N: operaattorin valinnat

Operaattorin valinnoilla tarkoitetaan kaikenlaisia signaaleja, jotka ovat peräisin operaat-

torin valintanäytöillä tekemistä valinnoista. Lista kerättiin vanhoja projekteja ja standar-

ditauluja tutkimalla.

Ryhmä Q: analogiasignaalit

Ryhmä Q sisältää kaikki analogiasignaalit, jotka liittyvät mittauksiin ja niistä johdettuihin

arvoihin, laskureihin, ajastimiin ja parametrien syöttämiseen. Ryhmän haasteena oli saada

numerointi järkeväksi siten, että jokaiselle signaalityypille olisi riittävä määrä vapaita

tunnuksia ja numerointi erottelisi järkevästi turvajärjestelmän signaalit ja DCS-signaalit.

Ryhmä R: säätimen signaalit

36

Tämän ryhmän signaalit ovat säätimeen ja säätötapaan liittyviä. Asetusarvon ja säätöta-

van valintaan liittyvät signaalit olivat melko vakiintuneita, joten niihin ei ollut tarvetta

tehdä suuria muutoksia. Sen sijaan ryhmään haluttiin lisätä joitain säätöön liittyviä ana-

logiasignaaleja, kuten asetusarvoja ja säätimen lähtöjä, sillä näiden signaalien on mielek-

käämpää olla samassa ryhmässä muiden säätimien signaalien eikä yleisten analogiasig-

naalien ryhmässä.

Ryhmä S: sekvenssin askeleet

Nämä signaalit ovat tarkoitettu ainoastaan ilmaisemaan, missä askeleessa sekvenssi on

milläkin hetkellä. Numerointi on siis juokseva ja ainoa sääntö on käynnistys- ja pysäy-

tyssekvenssin erottelu.

Ryhmä U: logiikkasignaalit

Tässä ryhmässä ovat kaikki binääriset logiikkasignaalit ja numerointi on täysin juokseva.

Näitä signaaleja käytetään aina, kun kyseessä on jokin johdettu signaali, joten suurin osa

signaaleista kuuluu tähän ryhmään.

Ryhmä Z: turvajärjestelmän signaalit

Tämän ryhmän tunnukset toimivat samoin, kuin ryhmän U tunnukset, kun kyse on turva-

järjestelmässä johdetusta signaalista.

6.2 Suunnitteluohje

Työn toinen vaihe oli kirjoittaa suunnitteluohje signaalitunnusten käyttöön (ks. Liite 2).

Ohje kirjoitettiin englanniksi. Ohjeesta tuli käydä ilmi seuraavat asiat:

- Mitkä objektit tarvitsevat tunnuksen

- Hakeeko objekti tunnuksen standarditaulusta vai syötetäänkö se käsin

- Miten ja mihin attribuuttiin kunkin objektin tunnus on syötettävä

- Miten tunnus esitetään kuvissa

- Mitä tunnuksia käytetään erikoistapauksissa

Suunnitteluohjeessa esiteltiin myös esimerkkitapauksia numerointikäytännöistä, joiden

avulla suunnittelijan on helppo tehdä päätös tunnuksen lisäämisestä, mikäli projekti vaatii

uusien, mallikannasta löytymättömien objektien lisäämistä. Ohjeen on tarkoitus jatkossa

37

toimia suunnittelijoiden apuna tunnusten lisäämisessä. Ohjeen runko kirjoitettiin työn al-

kuvaiheessa ja sitä täydennettiin mallikannan päivityksen aikana aina kun vastaan tuli

epäselvä tilanne, joka vaati selitystä.

38

7 MALLIKANNAN PÄIVITYS

Mallikannan päivittäminen oli tehtävä hyvin järjestelmällisesti ja tarkkaa harkintaa käyt-

täen. Tästä syystä suurempia muutoksia tehtäessä lupa oli kysyttävä asiantuntijalta, joka

ymmärsi tarkasti mallikannan kokonaisuuden ja muutosten vaikutukset tietokannan mui-

hin osiin.

Mallikannan päivityksen edetessä vastaan tuli monia ongelmia, jotka johtuivat aiemmin

tehtyjen muutosten ja Comoksen yleisen käytön epäjärjestelmällisyydestä. Vapaasti mää-

riteltävien signaaliobjektien, näyttöobjektien, tila- ja hälytysobjektien ja väyläsignaaliob-

jektien tunnusten lisääminen onnistui ilman suurien muutosten tekemistä Comokseen,

mutta standardisignaalien ja muiden standarditauluja käyttävien objektien tunnusten

vaihtaminen ei onnistunut ilman mittavia muutostöitä. Tästä syystä muutokset siirrettiin

myöhemmäksi ja jätettiin tämä työn ulkopuolelle.

7.1 Muutosten yleiset vaikutukset

Ennen mallikannan päivityksen aloittamista oli testattava tehtyjen muutosten vaikutus

olemassa oleviin projekteihin. Huolimattomasta muutosten tekemisestä mallikantaan

olisi voinut seurata suuria ongelmia, sillä jokainen muutos vaikuttaa projekteihin, joissa

muutoksen kohdetta on käytetty. Mikäli esimerkiksi muokataan jonkin objektin attribuu-

tin skriptiä koskien tietojen automaattista hakua taulukoista, voidaan aiheuttaa tilanne,

jossa olemassa olevan projektin objekti ei enää löydä tietoa oikeasta sijainnista. Myös-

kään attribuuttien poistaminen ei ole järkevää, sillä jokin objekti voi käyttää kyseistä att-

ribuuttia. Sen sijaan uusien attribuuttien lisääminen on mahdollista.

Muutosten testaamista varten Comoksen mallikantaan luotiin uusi työskentelytaso, jonka

päällä tehdyt muutokset eivät vaikuttaneet varsinaiseen mallikantaan. Lisäksi valittiin

eräs suuri KKS-projekti, jolle luotiin myös työskentelytaso. Nämä tasot linkitettiin toi-

siinsa siten, että mallikannan tasolla tehdyt muutokset vaikuttivat vain tähän yhteen pro-

jektin tasoon.

39

7.2 Mallikannan standarditaulujen päivitys

Signaalitunnusten päivityksessä tarvittavat tiedot oli tallennettu lähinnä kahteen standar-

ditauluun, jotka oli Comoksessa merkitty otsikoilla ”KP36 Trigger KKS label” ja ”KP38

Control signals KKS label”. KP36:sta löytyy raja-arvo-objektien tunnukset ja KP38:sta

sekvenssien, yksittäisten laitteiden, säätimien ja operaattorin valintasignaalien tunnukset

(kuva 16).

KUVA 16. Signaalitunnusten standarditaulut

Tauluissa määritetyt signaalitunnukset ovat lähtökohtaisesti vakiintuneita ja samoja jo-

kaisessa KKS-projektissa. Näitä tauluja ei pääsääntöisesti ole tarkoitus muokata projek-

tikohtaisesti, ellei asiakas esitä erillistä toivetta signaalitunnuksista.

Standarditauluja käyttäviä standardisignaaleja ovat seuraavat:

- Automaatiosekvensseihin liittyvät käynnistys-, pysäytys- ja suojaussignaalit

- Moottoreihin liittyvät käynnistys-, pysäytys-, suojaus- ja ohjaustapamuutossig-

naalit

- Säätöventtiileihin ja toimilaitteisiin liittyvät käynnistys-, pysäytys-, suojaus- ja

ohjaustapamuutossignaalit

- Säätimien asetusarvo-, suojaus- ja ohjaustapamuutossignaalit

- Operaattorin valintanäyttöjen ON-, OFF-, käynnistys- ja pysäytyssignaalit

- Analogisesta mittaustiedosta johdetut raja-arvovertailusignaalit

- Binääriset rajakytkinsignaalit

Tauluhiin syötettävät tunnukset on määritelty, mutta tauluja ei muokattu tämän työn puit-

teissa. Tarvittavat muutokset tullaan tekemään tulevaisuudessa suunnitelmien mukaan.

40

7.3 Signaalitunnuksiin liittyvät mallikannan objektien attribuutit

Signaalitunnuksien muokkaamiseen ja esitykseen liittyviä attribuutteja ovat seuraavat:

- RI.RI0007: määrittää objektin position näkymisen kuvassa. Voi saada joko arvon

0 (positio ei näy) tai 1 (positio näkyy).

- RI.RI0020: määrittää signaalitunnuksen tai objektin nimen näkymisen kuvassa.

Voi saada joko arvon 0 (tunnus ei näy) tai 1 (tunnus näkyy).

- RI.S019: määrittää grafiikkaskriptin, jota objekti käyttää graafiseen esitykseen.

Arvo on jonkin standarditaulusta löytyvän grafiikkaskriptin nimi.

- RI.S023: määrittää signaalitunnuksen. Arvo on aakkosnumeerinen signaalin

koodi, joka voidaan syöttää käsin tai valita standarditaulun arvoista.

- TD.MS02: määrittää objektin nimen näkyvyyden kuvassa. Voi saada joko arvon

0 (nimi ei näy) tai 1 (nimi näkyy).

Comoksessa useimmilla kohteilla oli jo valmiiksi olemassa nämä attribuutit, mutta niitä

ei kaikissa tapauksissa oltu skriptattu suorittamaan haluttua toimintoa. Tällöin attribuutti

näkyy asetusvalikossa oikein ja sille voidaan tehdä valintoja, mutta valinnat eivät vaikuta

kuviin. Attribuutti RI.S023 puuttui lähes jokaiselta Base-objektilta, paitsi standardisig-

naaliobjekteilta, joten se oli lisättävä ennen objektien muokkaamista.

7.4 Mallikannan Base-objektien päivitykset

Comoksen Base-objekteja luotaessa ei voida useinkaan tietää, minkälaisia päivityksiä ob-

jektit vaativat jatkossa ja siksi päivitys voi olla hankalaa myöhemmin. Useita Base-ob-

jekteja jouduttiin muokkaamaan ja päivittämään ennen kuin tunnukset oli mahdollista

syöttää ja esittää halutulla tavalla.

Signaalitunnukset lisättiin seuraaville objekteille:

- Vapaasti määritettävät signaaliobjektit

- Väyläsignaaliobjektit

- Tila/hälytys -objektit

- Standardisignaaliobjektit

- Raja-arvo-objektit

- Näyttö- ja laskuriobjektit

41

- Operaattorin valintaobjektit

- Säädettävien parametrien objektit

7.4.1 Objektien attribuuttien lisääminen asetusikkunaan

Objektien asetusikkunaan haluttiin näkyviin attribuutit, joiden avulla suunnittelija voi li-

sätä ja muokata signaalitunnuksia ja niiden näkyvyyttä helposti ja mahdollisimman no-

peasti. Useimmille objekteille haluttiin kuvan 17 mukaiset attribuutit.

KUVA 17. Tunnuksen näkyvyyden asetukset suunnittelijan näkymässä

Kuvan 17 mukaisesta valikosta voidaan valita pääposition ja signaalitunnuksen näkymi-

nen ja syöttää tunnus. Mikäli signaalitunnus-kenttä jätetään tyhjäksi, kuvaan ei tulostu

mitään pääposition perään.

Tällainen asetusikkuna toteutettiin kaikille muille, paitsi vapaasti määritettäville signaa-

liobjekteille ja väyläsignaali- ja tila/hälytys -objekteille. Näiden objektien tapauksessa

tunnus syötetään Label-attribuuttiin (kuva 18).

KUVA 18. Objektien Label -attribuutti Comoksessa

42

Vapaasti määriteltävien signaaliobjektien tapauksessa oli pohdittava suunnittelijoiden

valmiutta vaihtaa totuttua toimintatapaa. Jokainen suunnittelija, joka on aiemmin toimi-

nut KKS-projektien parissa, on joutunut pohtimaan signaalitunnuksia ja niiden valintaa.

Usein projekteja suunnitellaan kiireellä eikä uusien asioiden sisäistämiseen ja oikeiden

attribuuttien etsimiseen ole aikaa tai kiinnostusta. Tästä syystä päätettiin, että vapaasti

määriteltävien signaaliobjektien signaalitunnukset syötetään myös jatkossa objektin ase-

tusikkunan yläreunan kiinteään kenttään kuvan 18 mukaisesti.

Kuvassa 18 näkyvät kentät Name ja Label ovat näkyvissä Comoksen kuvaikkunan ylä-

reunan pikatyökalupalkissa, mikäli objekti on valittuna kuvassa. Tällöin tunnus on helppo

syöttää avaamatta asetusikkunaa lainkaan.

Tila/hälytys- ja väyläsignaaliobjektien tunnus päätettiin myös syöttää Label-attribuuttiin,

sillä silloin tunnus tulee näkyviin myös Comoksen puurakenteeseen. Tällöin suunnitteli-

jan on helppo nähdä heti, mitkä tunnukset on jo varattu eikä Comos anna syöttää kahdelle

objektille samaa tunnusta.

Muiden objektien tapauksessa oli luontevaa käyttää kuvassa 17 esitettyä KKS Label -att-

ribuuttia, sillä sen avulla saavutettiin yhdenmukainen käytäntö. Standardisignaalien ta-

pauksessa tunnusta joudutaan harvoin muokkaamaan, joten KKS Label -attribuuttia ei

asetettu näkyviin kuvan ylälaidan pikatyökaluriville. Näyttö-, laskuri-, valinta- ja para-

metriobjekteille on useammin tarve syöttää tunnus, joten niiden KKS Label -attribuutti

tuotiin näkyviin pikatyökaluriville.

7.4.2 Objektien esitys kuvissa

Tärkeä osa tunnusjärjestelmän järkevää toteuttamista oli se, että tunnukset saatiin näky-

viin kuviin objektien yhteyteen KKS-ohjeen määrittelemällä tavalla. Objektien esitysta-

pojen saaminen oikeanlaisiksi vaati Base-objektien grafiikkaskriptien muokkaamista.

Grafiikkaskriptit on tallennettu keskitetysti standarditauluihin, jolloin taulun skriptiä

muokkaamalla jokainen skriptiä käyttävä Base-objekti saa uuden ulkoasun käyttöönsä.

Suurin osa grafiikkaskripteistä oli jo aiemmin määritelty siten, että kuviin objektin yhtey-

teen tulostuu objektin pääpositio ilman signaalitunnusta. Signaalitunnuksen näkyvyys oli

43

saatava ehdolliseksi siten, että suunnittelijan on mahdollista valita objektin asetuksista,

halutaanko näkyviin KKS:n mukainen tunnus vai jokin muu tunnus tai nimi. Signaalitun-

nus pyrittiin saamaan näkyviin tarvittaviin Base-objekteihin. Kuvassa 19 on esitetty eräs

vaihtoehto skriptistä, jolla tämä voitaisiin toteuttaa.

KUVA 19. Skripti signaalitunnusta varten

Skriptin ensimmäisellä rivillä tarkistetaan, onko objektin positio asetettu näkyviin ku-

vaan. Jos positio on asetettu näkyviin, tarkistetaan rivillä 2 onko objektin nimi asetettu

näkyväksi. Jos nimi on asetettu näkyväksi, tulostuu kuvaan objektin positio ja nimi joko

erottavalla pisteellä tai ilman, riippuen siitä, onko kyseessä KKS-projekti vai ei. Muussa

tapauksessa kuvaan tulostuu positioteksti ja sen perään signaalitunnus attribuutista

RI.S023. Mikäli attribuutti on rivin 9 tarkistuksen mukaisesti tyhjä, tulostuu pelkkä posi-

tioteksti. Jos attribuutissa RI.S023 on sisältöä, rivillä 12 tarkistetaan, onko signaalitunnus

asetettu näkyväksi. Rivillä 18 määritetty teksti varsinaisesti tuodaan näkyviin koordinaat-

teihin, jotka on aiemmin skriptissä tallennettu muuttujaan p16. Rivin 18 lopussa olevat

kaksi ykköstä määrittelevät tekstin tasauksen keskelle pysty- ja vaakasuunnassa.

Useimpien objektien grafiikat päivitettiin kuvan 19 kaltaisella skriptillä. Jotkin Base-ob-

jektit oli rakennettu hieman eri tavalla, joten skriptiä ei voitu käyttää sellaisenaan, vaan

sitä jouduttiin muokkaamaan perusrakenteen pysyessä kuitenkin samana. Tuloksena saa-

tiin kuvan 20 mukaiset esitykset objekteille.

1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18 19 20

44

KUVA 20. Esimerkkejä tunnusten esityksestä

7.5 Yksittäisten signaalitunnusten lisäys

Signaalitunnusten lisääminen objekteille oli mekaanista ja aikaa vievää työskentelyä.

Tunnusten lisäämiseen ei keksitty parempaa keinoa, kuin jokainen mallikannan kuvan

läpikäynti yksitellen ja kuvassa esiintyvien objektien muokkaaminen signaalitunnuslistaa

apuna käyttäen.

Ensiksi luotiin kuvan 21 mukainen kysely, joka palauttaa kaikki mallikannan dokumentit.

45

KUVA 21. Dokumenttikysely kaikille dokumenteille

Kysely palautti myös joitakin dokumentteja, joita ei tässä tapauksessa tarvittu,

esimerkiksi dokumenttipohjia, joissa ei ollut positioitavia kohteita. Nämä dokumentit

suodatettiin kyselystä Unwanted-sarakkeen avulla. Sarakkeeseen syötettiin ehdot

tarpeettomille dokumenteille ja jätettiin näkyviin vain tarpeelliset dokumentit.

Ensimmäisenä lisättiin tunnukset vapaasti määriteltäville signaaleille. Dokumentit

avattiin yksitellen ja etsittiin jokainen lähtösignaali kuvasta. Kun signaali valittiin, voitiin

ikkunan yläreunan pikatyökalun avulla syöttää signaalitunnus avaamatta objektin

asetuksia. Lähtösignaaliobjektin tunnus periytyi automaattisesti tulosignaalin objektille,

joten niitä ei tarvinnut syöttää käsin.

Toisena lisättiin tunnuksen näyttö-, valintanäyttö- ja laskuriobjekteille. Tunnusten lisäys

suoritettiin samoin kuin vapaasti määritettävien signaalien tunnusten lisäys eli jokainen

kuva käytiin läpi yksitellen. Näyttöobjekteille ei oltu valmiiksi asetettu ikkunan yläreunan

pikatyökalua, sillä tunnusta ei syötetty kuvan 18 mukaisesti Label-attribuuttiin, vaan Ad-

ditional information KKS Label -attribuuttiin RI.S023. Attribuutti saatiin näkyviin pika-

työkaluriville avaamalla Base-objektin asetuksista attribuutti SYS.VSUI, joka sisältää lis-

tan attribuuteista, jotka halutaan näyttää pikatyökalurivillä, ja lisäämällä attribuutti

RI.S023 listaan (kuva 22).

46

KUVA 22. Attribuutin lisäys pikatyökaluihin

Kolmantena lisättiin tunnukset tila/hälytys- ja väyläobjekteille. Tunnukset lisättiin sa-

malla tavalla, kuin vapaasti määritettävien signaalien tunnukset eli objektin Label-attri-

buuttiin.

Tunnusten syöttämisen aikana tuli luonnollisesti vastaan kohteita, joita ei oltu aiemmin

tunnuslistaa tai ohjetta tehdessä osattu huomioida. Tästä syystä sekä listaa että ohjetta

päivitettiin aktiivisesti koko työn ajan. Ohjeen toimivuus ja ymmärrettävyys testattiin si-

ten, että signaalitunnuksia tuntematon henkilö otti ohjeen käyttöön ja lisäsi sen avulla

joitain tunnuksia mallikantaan. Tästä kokeesta saadun palautteen avulla listaa ja ohjetta

päivitettiin.

Vaikka lista ja ohje ovat melko kattavat ja tarkkaan harkitut, ne eivät ole kuitenkaan vielä

saavuttaneet lopullista muotoaan. Näitä dokumentteja tullaan jatkossa päivittämään uu-

sien tarpeiden ilmetessä.

47

8 COMOKSEN ONGELMAT JA JATKOKEHITYS

Standarditauluja käyttävien objektien tunnuksia ei voitu muuttaa, sillä tunnukset tulevat

suoraa tauluista ja joissain projekteissa taulut on kopioitu projektiin paikallisiksi ja jois-

sain tapauksissa jätetty linkitetyiksi mallikannan tauluihin. Tämän seurauksena muutos-

ten teko mallikannan tauluihin sekoittaisi osan vanhoista projekteista, mikä ei tietenkään

ole hyväksyttävää.

Myös objektien grafiikkaskriptit tallennetaan standarditauluihin, jolloin mallikannan

muutokset sekoittaisivat myös monien objektien esitykset kuvissa. Grafiikkaskriptien

muutokset oli tehty suurella varovaisuudella, mutta siitä huolimatta ei voitu olla varmoja,

onko muutoksilla ei-toivottuja vaikutuksia työskentelytason vapautuksen jälkeen. Kaikki

muutokset päätettiin siis jättää tasolle odottamaan jatkokehitystä.

Ongelmiin yritettiin kehittää ratkaisua, joka estäisi olemassa olevien projektien sekoitta-

misen. Eräs ajatus oli luoda Comokseen uusi attribuutti, joka antaisi käyttäjän valita, ha-

lutaanko uusi projekti toteuttaa vanhalla vai uudella positiointitavalla. Tällöin jokaisen

objektin skriptiin lisättäisiin ehto, joka tarkistaa tämän attribuutin tilan. Tämä ratkaisu

olisi toiminut monien grafiikkaskriptien tapauksessa. Joidenkin objektien skriptit oli kui-

tenkin toteutettu eri tavalla, jolloin ratkaisua ei voitu käyttää, tai se olisi vaatinut liian

suuria muutoksia saavutettavaan hyötyyn nähden.

Tässä vaiheessa järkevin ratkaisu vaikuttaisi olevan vanhojen projektien kaikkien tietojen

kopioiminen paikalliseksi, jolloin muutoksia voitaisiin tehdä vapaasti ilman riskiä pro-

jektien sekoittamisesta. Tällainen muutos kuitenkin vaatii tarkempaa pohdintaa ja hyväk-

synnän useilta tahoilta, joten sen mahdollinen toteutus siirtynee tulevaisuuteen. Myös jat-

kossa projektien tiedot olisi hyvä kopioida paikalliseksi, jotta tässä työssä esitettyjen päi-

vitysten kaltaiset muutokset olisivat mahdollisia ilman ylimääräisten attribuuttien luo-

mista ja skriptien liiallista muokkaamista. Nämä toimenpiteet aiheuttavat mallikantaan

sekavuutta ja vievät todella paljon aikaa, ja sitä kautta vaikuttavat työnteon mielekkyy-

teen ja taloudellisuuteen.

48

9 POHDINTA

Tämän työn tarkoituksena oli helpottaa Valmetin laitossuunnittelua päivittämällä malli-

kantaa nykyisiä tarpeita vastaavaksi ja luomalla tarvittavat listat ja ohjeet signaalitunnuk-

sien syöttämiseen. Tarve työlle syntyi alun perin suunnitteluun käytetyn turhan ajan ja

suunnittelijoiden turhautumisen kautta. Signaalitunnukset olivat sellainen suunnittelun

vaihe, jota moni suunnittelija ei mielellään tehnyt.

Tämän projektin aikana luotu signaalitunnusjärjestelmä vastaa teoriassa nykyisiä tarpeita

suunnittelua ajatellen. Koska työtä varten on käyty läpi runsaasti vanhoja ohjeita ja aiem-

pia projekteja, voidaan uutta järjestelmää pitää eräänlaisena yhdistelmänä vanhojen jär-

jestelmien parhaista puolista. Lopullisen arvion järjestelmän toimivuudesta voi kuitenkin

antaa vasta, kun se on otettu käyttöön muutamassa uudessa KKS-projektissa. Myös asi-

akkaiden mielipiteet vaikuttavat siihen, onko järjestelmää mielekästä käyttää tällaisenaan,

vai vaatiiko se jatkossa paljon päivittämistä.

On selvää, että suunnittelutyön kehittyessä jatkuvasti ja uusien tarpeiden syntyessä jär-

jestelmää on myös kehitettävä eteenpäin. Jatkoa ajatellen kuitenkin helpottaa se, että sig-

naalitunnuksien ollessa Comoksen mallikannassa niiden muokkaaminen suurina erinä on

suhteellisen nopeaa. Tämä projekti on siis luonteeltaan jatkuva ja vaatii myös tulevaisuu-

dessa parantelua sekä varsinaisten signaalitunnuksien että Comoksen kehittämisen osalta.

Tämä työ toteutettiin täysin toimeksiantajan ohjeiden mukaisesti ja ennen työn alkua

määritettyjen aikarajojen puitteissa. Työn laajuus oli aluksi jätetty hieman avoimeksi,

mutta työn edetessä kävi selkeästi ilmi, mihin asioihin olisi paneuduttava, jotta tulos olisi

mahdollisimman hyvä. Esimerkiksi Comoksen päivittäminen vaati toisaalta suuriakin

muutoksia, mutta ilman näitä muutoksia uuden järjestelmän toteutus ei olisi ollut mah-

dollinen. Kokonaisuutena tähän mennessä tehty työ oli erittäin onnistunut ja antoi hyvät

edellytykset järjestelmän jatkokehitykselle.

49

LÄHTEET

Bloomberg L.P. Company. N.d. Overview of Comos Industry Solutions GmbH (Aus-

tria). Luettu 9.7.2018.

https://www.bloomberg.com/research/stocks/private/snapshot.asp?privca-

pId=104813210

Kaiser, J., Königstein, H. & Müller, H. 2007. RDS-PP – Transition from the KKS

to an international standard. VGB 8/2007.

Kuningas, S. 2011. COMOS suunnitteluohje. Säätö-, lukitus- ja

sekvenssisuunnittelu. Revisio 1,5.

Microsoft. 2018. What Is VBScript?. Luettu 9.7.2018.

https://msdn.microsoft.com/en-us/library/1kw29xwf.aspx

Nanjing Luculent Co., Ltd. N.d. KKS Code. Luettu 9.7.2018.

http://www.wut-luculent.com/Product/ProductDetails.aspx?Siteid=2&mid=87&id=28

Nissinen, J. 2007. Verkostoituneen sähköistys- ja instrumentointiprojektin detaljisuun-

nittelun tiedonhallinnan automatisointi. Automaatiotekniikan koulutusohjelma. Tampe-

reen teknillinen yliopisto. Diplomityö.

Siemens AG. 2013. COMOS Platform Operation. Operating Manual.

https://cache.industry.sie-

mens.com/dl/files/470/83235470/att_30826/v1/COMOS_Platform_Operation_enUS_en

-US.pdf

Siemens AG. 2018a. Plant engineering software. Luettu 9.7.2018.

https://w3.siemens.com/mcms/plant-engineering-software/en/Pages/Default.aspx

Siemens AG. 2018b. COMOS at a glance. Luettu 8.8.2018.

https://w3.siemens.com/mcms/plant-engineering-software/en/comos-overview/pa-

ges/default.aspx

Tiikko, S. 2015. COMOS Basic Training. Revisio 10.

Valmet Oyj. 2018a. Valmet yrityksenä. Luettu 9.7.2018.

https://www.valmet.com/fi/valmet-yrityksena/

Valmet Oyj. 2018b. Liiketoiminnat. Luettu 9.7.2018.

https://www.valmet.com/fi/valmet-yrityksena/valmet-lyhyesti/liiketoiminnat/

Valmet Oyj. 2018c. Valmetin toiminnot Suomessa. Luettu 9.7.2018.

https://www.valmet.com/fi/valmet-yrityksena/valmet-suomessa/

Valmet Oyj. 2018d. Avainluvut. Luettu 9.7.2018.

https://www.valmet.com/fi/valmet-yrityksena/valmet-lyhyesti/avainluvut/

50

VGB PowerTech. 2004a. KKS- Identification System for Power Stations VGB-B 106A

E. Essen: VGB PowerTech e.V.

VGB PowerTech. 2004b. KKS- Identification System for Power Stations VGB-B

106B1 E. Essen: VGB PowerTech e.V.

VGB PowerTech. 2004c. KKS- Identification System for Power Stations VGB-B

106B4 E. Essen: VGB PowerTech e.V.

Virtanen, J. 2008. Kattilalaitoksen instrumentointi- ja sähköistysdetaljisuunnittelutyöka-

lujen kehittäminen. Automaatiotekniikan koulutusohjelma. Tampereen teknillinen yli-

opisto. Diplomityö.

51

LIITTEET

Liite 1. Lista signaalitunnuksista

Note! These instructions can and will be changed in the future. This version is only made

for the publication of the thesis. To get the current version, please contact the author of

this thesis.

52

53

54

55

56

57

58

59

60

61

Liite 2. Ohje KKS-signaalitunnusten käyttöön

Note! These instructions can and will be changed in the future. This version is only made

for the publication of the thesis. To get the current version, please contact the author of

this thesis.

TABLE OF CONTENTS

1 ITEMS TO BE POSITIONED

2 GENERAL PRINCIPLES

2.1 Standard signals

2.2 Triggers

2.3 Freely defined signals

2.4 Bus signals

2.5 Status/Alarm objects

2.6 Indication and counter objects

2.7 Operator selection signals

2.8 Adjustable parameter values

3 POSITIONING CONVENTION

3.1 Derived safety system signals and transfer via bus

3.2 Analog measurement signals

3.3 Derived analog signals

3.4 Triggers of safety system

3.5 Signals transferred from DCS to SIS

3.6 Status/Alarm objects in DCS

3.7 Running status in SIS

3.8 Double positions

3.9 Adjustable parameters

3.10 Measurement selection

62

1 ITEMS TO BE POSITIONED

KKS signal tags are needed for following objects:

1. Standard signals for valves, controllers, motor controllers etc.

2. Triggers

3. Freely defined signals

4. Bus signals

5. Status/Alarm objects

6. Indication objects (optional)

7. Operator selection signals (optional)

8. Adjustable parameter values (optional)

63

2 GENERAL PRINCIPLES

2.1 Standard signals

KKS codes for these signals are defined centrally in standard tables.

The meaning of these signals is standardized. The objects in KKS projects get signal

codes automatically from standard table. Codes are located in attribute RI.S023. The cor-

responding signal codes are shown in Appendix 1.

Signal code can be given manually:

Properties Attributes Presentation Additional information KKS Label

If the code is given manually, it will replace the original code gotten from the standard

table.

2.2 Triggers

KKS codes for trigger objects are defined centrally in standard tables.

The meaning of these signals is standardized. The objects in KKS projects get signal

codes automatically from standard table. Codes are located in attribute RI.S023. The cor-

responding signal codes are shown in Appendix 1.

64

Signal code can be given manually:

Properties Attributes Presentation Additional information KKS Label

If the code is given manually, it will replace the original code get from the standard table.

2.3 Freely defined signals

The signal code for these signals shall be given case by case based on the purpose of the

signal. Standardized signal codes are shown in Appendix 1. If there is no defined code

for signal, the code from corresponding set with sequential numbering must be used.

The signal code is given to the Label attribute of the OUT object. The code is transmitted

automatically to IN object located below. The code will be shown in the drawing after the

KKS position on the center line of the signal object.

Signal code is entered manually:

Properties Label

65

2.4 Bus signals

The signal code for all bus signals shall be given based on the purpose of the signal.

Signal code is entered manually:

Properties Label

2.5 Status/Alarm objects

Single Status/Alarm objects located in I&C folder must be given signal codes.

The code will be shown in the drawings above the Status/Alarm object on the bottom line

after the KKS position.

Signal code is entered manually:

Properties Attributes Presentation Additional information KKS Label

Note! The Status/Alarm object under the bus signal get its the code from the bus object

and does not need it to be given separately.

66

2.6 Indication and counter objects

This code is optional! The signal code for indication objects shall be given case by case

based on the value indicated on the display. The code for counter objects is the standard-

ized signal code shown in Appendix 1.

The code will be shown in the drawings above the indication or counter object on the

bottom line after the KKS position.

Signal code is entered manually:

Properties Attributes Presentation Additional information KKS Label

2.7 Operator selection signals

This code is optional! The signal code for selection faceplate in control diagrams shall be

given case by case based on the type of selection. Selection faceplate status signals get

signal codes automatically from standard table.

Signal code is entered manually:

Properties Attributes Presentation Additional information KKS Label

67

2.8 Adjustable parameter values

This code is optional! The signal code for the object of adjustable parameter values shall

be given manually.

Signal code is entered manually:

Properties Attributes Presentation Additional information KKS Label

2.9 Entering the signal code

The signal code is entered to Label attribute for following objects:

- Freely defined signal objects

- Bus signal objects

68

The signal code is entered to Additional information KKS Label attribute for following

objects:

- Status/Alarm objects in I&C folder

- Standard signals for valves, controllers, motor controllers etc.

- Triggers

- Indication objects

- Operator selection objects

- Adjustable parameter values

69

3 POSITIONING CONVENTION

3.1 Derived safety system signals and transfer via bus

The binary signals generated by the safety system are numbered by sequential numbering

from the set XZ.

If the signal is transferred from SIS to DCS or BMS, the signal gets numbering from the

bus signal set XD as the number remains the same. Also, the bus signal object gets the

same code.

3.2 Analog measurement signals

Analog signals generated from the measurements are numbered from the set XQ.

The raw measurement in safety system gets the code XQ91 and the derived measurement

in safety system get code XQ51. When the measurement signal is transmitted analogously

via the bus to the DCS, it gets the code XQ01.

If the raw measurement is transferred directly from the transmitter to DCS and some cal-

culations will be performed later, the signal gets the code XQ41. The derived measure-

ment signal gets the code XQ01.

70

If no calculations are performed on the signal, then it gets directly the code XQ51 or

XQ01. Therefore, the raw measurement code will only be used if a calculation is per-

formed.

The fixed values given by the operator are handled like the analog measurement signals.

71

3.3 Derived analog signals

If the analog signal is derived in a software loop, for example as a sum of several other

signals, it gets the code from the set XQ so that the DCS signals get the code XQ11-

XQ19 and the SIS signals get the code XQ61-XQ69. If more numbers are needed, the

sequence can be extended to XQ21-XQ29 and XQ71-XQ79.

If the analog measurement signal is obtained by deriving from the original measurement

by changing the unit, it gets the code XQ01, as it is the final output of the measurement.

72

3.4 Triggers of safety system

The binary signals generated by the triggers of the safety system's analogue measurements

get the code from set XH.

If the signal is transferred to DCS, the signal gets the code from the set of bus signals XD

as the number remains the same.

Note! The same signal code is used for the bus transfer object and its Status/Alarm object,

as well as the outgoing DCS signal.

If there is a delay shorter than 30 seconds after the trigger, the signal after the delay is

considered to be same as the signal before the delay, as the delay acts as a filter for signal.

73

If the delay is 30 seconds or longer, the signal after the delay is considered to be separate

and therefore its code shall be given from general set XZ.

3.5 Signals transferred from DCS to SIS

When the signal is transferred from DCS to SIS, it gets the code from set XD as the

number remains the same.

3.6 Status/Alarm objects in DCS

The Status/Alarm signal generated from binary DCS signal without transferring via bus

gets the same code as the trigger object. Standardized signal codes are shown in Appendix

1.

74

The Status/Alarm signal generated from binary switch data in DCS gets the same code as

the switch object. Standardized signal codes are shown in Appendix 1.

If the Status/Alarm signal is generated from multiple binary signals, it gets the code from

set XU by sequential numbering.

In other cases, the Status/Alarm object gets the code from set XM as shown in Appendix

1.

75

3.7 Running status in SIS

If the running status of the device is transferred to SIS, the signal gets the code from set

XB as shown in Appendix 1.

3.8 Double positions

If two or more individual objects are located under the same main position and it is not

possible to separate them with the signal code, the alphabetic extension must be added.

76

3.9 Adjustable parameters

The adjustment setpoint object must be used as the object for adjustable parameter setting

by the operator. Object gets the code from set YQ11-YQ19.

3.10 Measurement selection

The selection faceplate object used for the signal selection gets the code XN21. The me-

dian or average derived from the analogue measurement signals gets the code XQ in ac-

cordance with Appendix 1. The measurement signal after the signal selection gets the

code XQ01 so that the signal is immediately recognized as the final output of the meas-

urement.