kks-signaalitunnusjärjestelmän kehittäminen
TRANSCRIPT
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.
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.