Modelling and simulation of shipyard production processes

TEKNILLINEN KORKEAKOULU Automaatio-ja systeemitekniikan osasto

LAIVANRAKENNUKSEN TUOTANTOPROSESSIEN MALLINNUS JA SIMULOINTI

Paavo Koti nurmi

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 14.5.2001 Työn valvoja: prof. Martti Mäntylä

Työn ohjaaja: DI Matti Paljakka

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä:

Paavo Kotinurmi Työn nimi:

Laivanrakennuksen tuotantoprosessien mallinnus ja simulointi Päivämäärä:

14.5.2001 Sivumäärä: 124

Osasto:

Automaatio-ja systeemitekniikka.

Pääaine:

Viestintä yritystoiminnassa.

Työn valvoja:

Prof. Martti Mäntylä Työn ohjaaja:

DI Matti Paljakka

Työssä tutkittiin laivanrakennuksen tuotantoprosessien simulointimahdollisuuksia suomalaisilla telakoilla. Prosesseista keskityttiin terästuotannon prosesseihin raakateräksestä rakennusaltaaseen. Mallirmusmetodologioita tutkittiin prosessien mallintamista ja mallin toiminnan dokumentointia ajatellen. Tutkittuja metodeita olivat EDEF-metodit sekä UML.

Valmistusprosessien simulointeihin tarkoitetuista simulointiohj elmistotuotteista valittiin tarkasteltaviksi Taylor ED, eM-Plant, QUEST, Arena, ProModel, WITNESS ja SimulS. Lisäksi tutkittiin erilaisia tiedonsiirtoratkaisuja

simulointimallin tarvitseman lähtötiedon, prosessin kuvauksen sekä mallilogiikan siirtämiseen. Työssä muodostettiin skenaarioita sekä pitkän aikavälin strategiseen että lyhyen aikavälin operatiiviseen simuloinnin käyttöön. Työssä tutkittiin myös maailmalla jo tehtyjä simulointeja. Lisäksi tarkastellaan telakoiden

tuotantoprosessien simuloinnin erityispiirteitä.

Tutkittujen vaihtoehtojen perusteella työn asiakkaille tehtiin suosituksia käytettävistä metodologioista, työkaluista ja käyttökohteista. Myös pahimmat riskit ja ongelmakohdat tunnistettiin. Suositukset toimivat pohjana telakoiden jatkopyrkimyksille ottaa simulointi käyttöön päätöksenteon tukivälineenä.

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER’S THESIS

Author:

Paavo Kotinurmi Title of thesis:

Modelling and simulation of shipyard production processes

Number of pages: 124 Date: 14.5.2001

Department:

Automation and Systems Technology.

Professorship:

Information Processing Science Supervisor:

Professor Martti Mäntylä Instructor:

Matti Paljakka M.Sc.

This thesis studied possibilities of simulating production processes in Finnish shipyards. Study concentrated on processes from initial plate processing to dry dock. Modelling methodologies were studied for modelling of processes and documenting the simulation model. Methodologies studied were IDEF-methods and UML.

From the simulation software suitable for manufacturing simulation Taylor ED, eM-Plant, QUEST, Arena, ProModel, WITNESS and SimulS were assessed. Also data modelling of simulation model logic, process description and input was studied as well as standards available to help the integration effort. Various scenarios were built of the actual usage of simulation at strategic and operational level. Also benchmarking simulation experiences from simulations already done.

Characteristics of shipbuilding regarding simulation efforts were also studied.

According to study recommendations were made concerning software tools, modelling methodologies, documentation and also were to start the use of simulation. Also main risks were and potential problem areas were identified.

Recommendations work as the basis of further attempt of using simulation as a tool to support decision making in production planning within shipyards.

Keywords:

Shipyard, modelling, simulation, production planning, XML, system integration, UML, IDEF, simulation software, one of a kind production, engineer to order manufacturing.

ALKULAUSE

Kiitän lämpimästi työn valvojaa ja ohjaajaa heidän taijoamastaan avusta. Haluan kiittää myös projektin osapuolia yrityksissä, jotka osallistuivat projektiin. Mainitsen erityisesti Jukka Seppälän Aker Finnyardsilta, jonka kanssa keskustelimme paljon projektin ongelmakentästä. Omat arvokkaat näkökulmansa toivat mukaan myös Johan Fransman ja Seppo Väätämöinen Masa-Yardsin edustajina.

Sain työn aikana arvokasta apua myös eri puolilta, joista haluaisin mainita Flensburgin telakan simulointiin erikoistuneen väen, joiden luona kävimme vierailulla. VTT Teollisuusautomaatio antoi hyvät puitteet työn tekemiselle ja ryhmän pitkäaikainen kokemus simuloinnin soveltamisesta auttoi huomattavasti eri osa-alueiden analysoinnissa.

Minulla oli mahdollisuus lisäksi osallistua konferenssiin Floridassa 9-13.12, josta oli suuri apu kokonaiskuvan luomisessa tapahtumapohjaisen simuloinnin käytön laajuudesta ja tulevaisuudesta sekä keskustella eri ohjelmistojen edustajien kanssa.

Suurin kiitos kuuluu rakkaalle avovaimolleni Katri Rajalalle arvokkaista kommenteista ja tuesta, jota sain työn aikana.

Espoo 4.5.2001

Sisällysluettelo

DIPLOMITYÖN TIIVISTELMÄ...

ABSTRACT OF THE MASTER’S THESIS ALKULAUSE...

SISÄLLYSLUETTELO...

1 JOHDANTO...

1.1 Yleiskuvaus ja ongelma...

1.2 Suomalaiset telakat...

1.2.1 Aker Finnyards...

1.2.2 Masa-Yards...

1.3 Tyypillisen laivanrakennusprojektin kulku...

1.4 Tuotannon suunnittelun nykytila... ...

1.5 Mitä halutaan saavuttaa simuloinnilla...

1.6 Tietojärjestelmien automatisoidut saarekkeet...

1.7 Laivanrakennus ja virtuaaliset yritykset...

2 TUOTANTOPROSESSIEN MALLINTAMINEN...

2.1 Mallintamistekniikat...

2.1.1 UML...

2.1.2 IDEF...

2.1.3 Muut mallinnustavat...

2.1.4 Suositukset mallintamistekniikoista...

2.2 Tekniikat tiedonsiirtoon...

2.2.1 STEP... :...

2.2.2 XML...

2.2.3 Muut tekniikat...

2.3 Rakennustapasuunnitelman muoto...

2.4 Tietolähteet...

2.5 Mallin yksityiskohtataso...

2.6 Komponenttien ja mallikirjaston luominen...

3 TUOTANTOPROSESSIEN SIMULOINTI...

3.1 Yleistä tuotannon simuloinnista...

3.2 Simulointi valmistusteollisuudessa...

3.3 Standardit toteutustavat...

3.3.1 H LA hajautettuihin simulointeihin... . 3.3.2 SDX simulointimallilogiikan siirtoon... . 3.3.3 Neutraalit mallikirjastot... . 3.4 Simuloinnin käyttökohteita...

3.5 Simuloinnin hyödyt ja niiden mittaaminen...

3.6 Simuloinnin heikkoudet...

3.7 Simuloinnin rooli yrityksen tietojärjestelmissä...

3.8 Simulointimetodit...

3.8.1 Tapahtumapohjaisen simuloinnin tulosten ja lähtötietojen analysointi

3.8.2 Verifiointi, validointi ja akkreditointi... . С^смсмсмсосооооосооосоооооооCNIc\|CNJCMCNJ Т-СМОО'Ч-OOOCMI'-N.OOOOO)cøcoooo>

о

< < =

3.9.2 Simuloinnit paperiteollisuudessa...

3.9.3 Panosprosessien simulointi...

3.9.4 Tilauskohtaisen tuotannon simulointi...

4 KAUPALLISET SIMULOINTIOHJELMISTOT...

4.1 Simulaatio-ohjelmien markkinat...

4.2 Oliosuuntautunut vai prosessiorientoinut simulointiohjelma 4.3 Simulointiohjelmiston valinta...

4.3.1 Simulointiohjelmiston valinnassa huomioitavaa...

4.3.2 Valintaprosessi...

4.4 Simulointiohjelmistot...

4.4.1 Taylor Enterprise Dynamics...

4.4.2 eM-Plant...

4.4.3 QUEST...

4.4.4 WITNESS 4.4.5 Arena...

4.4.6 4.4.7 4.4.8

4.4.9 Muut simulointiohjelmat...

4.5 Valintakriteerit...

4.5.1 Käyttäjä ja mallintaja...

4.5.2 Ohjelmisto...

4.5.3 Toimittaja...

4.5.4 Ohjelmistojen kypsyys...

4.6 Design Rationale ohjelmiston valinnasta.

5 SIMULOINNIN KÄYTTÖKOKEMUKSIA LAIVANRAKENNUSTEOLLISUUDESSA ..69

5.1 Flensburger Schiffbau-Gesellschaft...

5.2 Electric Boat Corporation...

5.3 Kvaerner Masa-Yards Helsingin telakka....

5.4 Aker Mäntyluoto...

5.5 Meyer Werft...

5.6 F incantieri...

5.7 Newport News Shipbuilding...

5.8 NASSCO...

5.9 Odense Steel Shipyard...

6 SIMULOINNIN KÄYTTÖSKENAARIOT..

6.1 Johdon strateginen suunnittelun apuväline 6.1.1 Taustaa...

56 57 ProModeL

Simul8...

Factor/Aim

57 58 59 60 61 62 62 63 64 65

69 72 73 75 76 77 78 79 80 82 82 82 3.8.3 Sosiaalinen simulointi

3.9 Miten suomalaisten telakoiden tuotantoprosessien simulointi eroaa muun teollisuuden simuloinneista.

3.9.1 Ylei

39 39

Wl'O-iOCOCOOt-b.-P*-O

^

6.1.7 Validointi...

6.1.8 Käyttöliittymät...

6.1.9 Turvallisuusasiat...

6.2 Operatiivisen tuotannonsuunnittelun apuväline 6.2.1 Taustaa...

6.2.2 Tavoite...

6.2.3 Mallissa käytettävä tieto...

6.2.4 6.2.5

6.2.6 Simulointimallin arkkitehtuuri...

6.2.7 Validointi...

6.2.8 Käyttöliittymä...

6.2.9 Turvallisuusasiat...

6.3 Käyttöliittymästä yleisesti...

7 JOHTOPÄÄTÖKSET JA SUOSITUKSET

7.1 Yleistä...

7.2 Mallintaminen...

7.3 Ohjelman valinta...

7.4 Käyttäjä...

7.5 Mitä prosesseja simuloidaan...

7.6 Integrointi muihin käytettyihin laitteisiin...

7.7 SWOT...

7.8 Onnistumisen edellytykset...

7.9 Simuloinnin käyttöönotto...

8 TUTKIELMAN ARVIOINTIA...

86 87 87 87 87 88 88 Tulokset... .

Mallin rakentamisessa huomioon otettavaa

89 90 90 91 92 92 92 94 94 95 96 97 98 98 99 101 101

103 9 YHTEENVETO

LÄHTEET...

LYHENTEET...

104 105 113

1 Johdanto

1.1 Yleiskuvaus ja ongelma

Suomen telakoilla tehdyt laivat ovat tyypillisesti tilauksen perusteella räätälöityjä laivoja.

Tuotannossa prosessit eroavat tilauksittain ja ihmisten tekemän työn osuus on suuri. Tämä tekee tuotannon pullonkaulat dynaamisiksi. Laivanrakennuksen tuotantoprosesseissa on paljon rajoituksia ja riippuvuuksia, jotka pitää ottaa huomioon tuotantosuunnitelmia tehtäessä. Tämä vaihtoehtojen suuri määrä hankaloittaa tuotannon suunnittelua ja aiheuttaa suuria paineita tietojen keräämiselle. Ongelmana onkin tuotannon suunnitteluvaiheessa hallita riippuvuudet ja saada tuotanto mahdollisimman sujuvaksi. Suunnittelijoiden ratkaistavia kysymyksiä ennen tuotannon aloitusta ovat muun muassa: Miten lohkojen tuotantoaikataulu ja sijoitukset saadaan tehdyiksi tehokkaimmin? Mikä on kokonaisedullisin rakennustapa? Miten eri resurssien käyttö optimoidaan? Miten viivästyksien ja suunnittelumuutosten negatiiviset vaikutukset saadaan minimoiduiksi?

Karmattaako tehdä itse vai ostaa alihankintana?

Rakentamisen aikana syntyy aina myös uusia ongelmia, joita pitää ratkaista. Näitä tilanteita ovat häiriöt, suunnitelmien muutokset ja viiveet. Esimerkiksi yksittäinen työvaihe jää tehtäväksi myöhemmin, jos tarvittavat materiaalit ovat myöhässä. Tästä kaikesta johtuen tuotannon suunnittelu vaatii paljon resursseja ja suunnittelua voidaan joutua uusimaan projektin aikana monta kertaa. Riippuvuuksien ja dynaamisten ilmiöiden suuri määrä aiheuttaa myös sen, että hyödyllistenkin muutosten tekeminen voi jäädä tekemättä, koska muutos vaatii monen ihmisen tarkistuksen.

Ongelmaan apu voi tulla simuloinnista, joiden avulla näitä dynaamisia muutoksia ja monimutkaisia riippuvuuksia voidaan hallita (Andersson, 1998). Simuloinnin avulla on mahdollisuus testata useampia vaihtoehtoja virtuaalisella mallilla tuotannosta.

Laivanrakennuksen tuotannon simulointimalli voisi toimia eri vaihtoehtojen testaamisessa apuna, jolloin kokeilujen tekemisen riskit pienenisivät. Simuloimalla voitaisiin myös tarkastella eri muuttujien vaikutusta tuotantoon ja kohdentaa resurssit oleellisimpien

1.2 Suomalaiset telakat

1.2.1 Aker Fmnyards

Aker Firmyards harjoittaa telakkatoimintaa Raumalla. Yhtiö on erikoistunut asiakasräätälöitäviin erikoisaluksiin. Telakka on tehnyt matkustaja-autolauttoja, risteilijöitä, tutkimuslaivoja, ro-ro laivoja, hinaajia, jäänmurtajia ja sota-aluksia sekä tehnyt myös lohkoja alihankintana muille telakoille. Aker Finnyards on 100%

noijalaisomistuksessa. Yhtiö kuuluu Aker Yards -konserniin. Telakalla on vakinaista omaa työvoimaa noin 800 työntekijää ja 200 toimihenkilöä.

Telakalla on 260 metriä pitkä ja 85 metriä leveä kuivatelakka. Nostokapasiteettia on rakennusaltaalla 300 tonnia. Verrattuna Masa-Yardsin kahteen telakkaan ovat Raumalla tehtävät alukset pienempiä ja siten telakat eivät juuri kilpaile samoista tilauksista.

Raumalla on tyypillisesti enemmän tilauksia samaan aikaan valmisteilla, koska yksittäiset tilaukset ovat pienempiä. Telakan nykyisen tilauskannan (maaliskuu 2001) arvo on yli 3 miljardia markkaa, josta viimeisten laivan luovutus tapahtuu kevääällä 2003.

Raumalla laivalohkoista suurin osa tehdään omin voimin, ja jonkin verran lohkoja tehdään myös alihankintoina muille telakoille. Alihankkijoita käytetään paljon suunnittelussa, varustelussa ja jonkin verran myös terästuotannossa. Esimerkiksi maalauksen hoitavat alihankkijat telakan tiloissa.

1.2.2 Masa-Yards

Kvaerner Masa-Yards on suomalainen laivanrakennusyhtiö, joka on erikoistunut suunnittelemaan ja rakentamaan risteilijöitä, RoPax-tyyppisiä matkustaja-aluksia sekä muita yksittäistuotantotyyppisiä aluksia kuten esimerkiksi jäänmurtajia. Päätuotteita ovat luksusristeilijät ja matkustaja-alukset. Kvaerner Masa-Yards on osa Kvaerner ASA konsernia.

Suomessa Masa-Yardsilla on telakka Turussa ja Helsingissä. Turussa on henkilökuntaa 2300 ja suurin rakennusallas Suomessa (365 x 80 x 10 m). Helsingin telakan koko on hieman pienempi. Henkilökuntaa on 1800 ja katetun rakennusaltaan koko on Panaman kanavan dimensioiden mukainen (280.5 x 34 x 9.5 m). Lisäksi Kvaerner Masa-Yardsiin kuuluu Piikkiö Works, Technology ja Marine itsenäisinä yksikköinä. Piikkiössä

valmistetaan asennusvalmiita modulaarisia hytti- ja kylpyhuoneyksiköitä laivoihin, offshore-rakenteisiin sekä hotelleihin. Piikkiö Works työllistää noin 230 ihmistä Piikkiössä, lähellä Turkua. Kvaerner Masa-Yards Technology ja Kvaerner Masa Marine ovat itsenäisiä yksiköitä, jotka tarjoavat asiakkaille meriteollisuuteen liittyviä palveluita, kuten suunnittelua ja tuotekehitystä. Kvaerner Masa-Yardsin kokonaishenkilöstömäärä on noin 4300. Masa-Yardsilla alihankkijoiden osuus prosesseissa on merkittävä.

Alihankkijoita on erityisesti varustelupuolella suunnittelussa ja toteutuksessa, mutta jonkun verran myös teräspuolella rungonkasaamiseen liittyvissä prosesseissa tekijöinä sekä suunnittelijoina. Tuotannossa on ollut ongelmana suunnittelun puutteen aiheuttamia töiden myöhästymisiä, moninkertaisia materiaalikustannuksia ja alihankkijaketjujen kanssa on ollut ongelmia (Raivio, 2000).

1.3 Tyypillisen laivanrakennusprojektin kulku

Koska laivat suunnitellaan asiakaskohtaisesti, on myös projektien kestot hyvin erilaisia.

Projektin kulku on kuitenkin suhteellisen samanlainen. Telakoiden asiakkaiden lukumäärä on aika pieni, koska varustamoja ei maailmalla ole niin kauhean paljon. Telakat osallistuvat kansainvälisiin tarjouskilpailuihin, joita on käynnissä samanaikaisesti useita.

Toimitusaika ja hinta ovat tärkeimpiä asioita sopimuksista neuvotellessa. Telakat laskevat tätä varten kriittisten resurssien perusteella mahdollisen luovutuspäivämäärän, mikä sitten määrää eri valmistusvaiheiden sekä suunnittelun valmistumista. Eri vaiheiden kestot riippuvat projektin laajuudesta ja tilauksen erikoisuudesta. Raumalla tyypillisen laivanrakennusprosessin kesto on tuotannonsuunnittelij a Jukka Seppälän mukaan seuraavanlainen: Sopimuksesta osavalmistuksen aloittamiseen menee tyypillisesti 5-6 kuukautta ja tästä luovutukseen kuluu aikaa noin 14 kuukautta. Helsingin ja Turun telakoilla prosessit ovat pidempiä, koska suunnittelua ja varustelua on suurissa loistoristeilijöissä paljon enemmän.

Laivat jaetaan suunnittelussa järjestelmittäni, alueittain ja lohkoittain. Laivan perussuunnittelu tehdään järjestelmittäni, työpiirustukset lohkoittain (runko) ja alueittain(varustelu). Järjestelmä)ako on toiminnallinen kuvaus laivasta, joka tehdään

altaassa. Lohkojen maksimipainot ja muut dimensiot riippuvat telakoiduin nostokapasiteeteista ja rakennuspaikkojen tiloista.

Ennen sopimusta tehtävään alkusuunnitteluun osallistuu muutamia henkilöitä. Tämän perusteella saadaan aluksen hinta ja aikataulu sekä karkeasti vaikutus tuotantoon. Jos saadaan tilaus, niin edetään perussuunnitteluun. Tämän tuloksena on laivan jäijestelmien toimintaa kuvaava aineisto, jonka avulla laiva voidaan hyväksyttää asianmukaisilla viranomaisilla, luokituslaitoksilla ja tilaajalla. Perussuunnitteluvaiheessa tilataan myös monia komponentteja, joissa on pitkät toimitusajat, kuten laivojen moottorit. Jossain tapauksissa tehdään jopa ennen kauppojen varmistumista alustavat sopimukset tällaisten komponenttien toimittajien kanssa. Myös muiden tärkeimpien alihankkijoiden kanssa tehdään tällöin sopimukset erilaisista kokonaistoimituksista. Perussuunnitteluaineisto toimii lähtötietona valmistussuunnittelulle. V almistussuunnittelu tehdään tila- ja lohkokohtaisesti. Lohkoille tehdään aikataulu, jonka mukaan resursseja ja tiloja varataan sekä teräs- että varustelutyövaiheisiin. Kun valmistussuunnittelu on tehty, alkaa tarkempi työsuunnittelu. Valmistussuunnitelman mukaisen aikataulun teon jälkeen on suurin osa kustannuksista lyöty lukkoon, koska vaikutusmahdollisuudet muuttaa aikatauluja ovat jatkossa pienemmät. Rakennustapasuunnitelma valmistuu perus- ja valmistussuunnittelun

aikana.

Valmistussuunnitelman päivämäärien avulla ajoitetaan työkuvien valmistuminen sekä lohkokohtaisten materiaalien tilaukset. Periaatteena on, että mahdollisimman suuri osa varustelusta saadaan tehtyä lohkojen kasausvaiheessa, jotta kuivatelakalla laivan kokoaminen olisi mahdollisimman nopeaa. On myös huomattavasti tehokkaampaa tehdä monet työvaiheet lohkon ollessa työn kannalta edullisimmassa asennossa. Kun lohkoihin liittyvät työkuvat ovat valmiit, tehdään yksityiskohtaisempi työnsuunnittelu, joka määrää tarkemmin resurssit ja reitit tuotannossa. Työvaiheiden aikataulun määrää valmistussuunnitelma.

Telakoilla on jokaisella omat erityispiirteensä, jotka vaikuttavat tuotannon ohjaukseen. Itse prosessit ovat hyvin samanlaisia ja laitteistoissakin erot ovat lähinnä kapasiteeteissa.

Turussa esimerkiksi on lohkojen kasaus- ja varastointipaikkoja riittävästi, jolloin yksittäisten työvaiheiden venytys onnistuu helpommin. Raumalla paikkoja on niukemmin, joten yksittäisen lohkon kasauksen yhteydessä aikataulu ei juuri jousta. Jos Raumalla lohkoa ei saada valmiiksi suunnitellussa ajassa, niin se täytyy lähettää prosessissa

eteenpäin, koska muuten tuotannon tukkeutuminen edellisissä prosessivaiheissa aiheuttavat vielä suuremmat ongelmat.

1.4 Tuotannon suunnittelun nykytila

Tuotannossa on käytössä useita erilaisia tietojärjestelmiä tuotetiedon hallintaan. Tuotteen ja tuotannon suunnittelun käytössä on erilaisia tietokoneavusteisia suunnitteluohjelmia

(CAD/CAM/CAE). Aikataulujen ja resurssikuormien suunnittelu tapahtuu toiminnanohj ausj äij estelmässä. Tuotannon suunnittelussa käytetyt ohjelmat ovat keskittyneet aikataulutukseen ja karkeaan resurssienhallintaan. Nykyisten tuotannon suunnittelun apuvälineiden puute on, että ne eivät pysty kertomaan mitään aikataulujen tehokkuudesta eivätkä havainnollista tuotannon dynamiikkaa. Lisäksi erilaisten rajoitusten testaus ei onnistu ja vaihtoehtojen tarkastelu on hidasta. Koska tuotannonsuunnittelijoilla on käytössään suuri määrä tietoa, rajoituksia ja vaihtoehtoja, on optimaalisen suunnitelman teko nykyisillä ohjelmilla hankalaa.

Tuotanto ei nykyisellään ole kovin modulaarista ja suunnittelutietojen uudelleenkäytettävyys on vähäisempää kuin monen muun teollisuudenalan tuotannossa.

Lohkojen modulaarisuus on vähäistä, koska yhdessä lohkossa voi olla esim. osa ravintolaa, keittiötä ja hyttejä. Tämä tekee lohkojen standardoinnin ja tuotetiedonhallinnan vaikeaksi.

Tuotantosuunnitelmien teossa on nykyään hyvin paljon niin sanottua hiljaista tietoa (tacit- tietoa), jota ei ole dokumentoituna missään. Tuotannon suunnittelun säännöt ovat tällä hetkellä vielä pitkälti sumean logiikan kaltaisia sääntöjä, jotka

valmistussuunnittelusta ymmärtää". Tämä tieto tulee saattaa eksplisiittiseen muotoon sääntöjen ja ohjeiden avulla ennen kuin nykyiset asiantuntijat siirtyvät eläkkeelle. Nykyisin tuotannon suunnittelussa henkilöstön keski-ikä on korkea ja heidän tiedon ja kokemuksen dokumentointi ei ole vielä systemaattista. Tätä hiljaista tietoa tulisi muutenkin pystyä välittämään eri sidosryhmille tehokkaammin paremman kokonaisoptimaalisen ratkaisun saavuttamiseksi.

"Erkki vain

1.5 Mitä halutaan saavuttaa simuloinnilla

kommunikointia, parantaa reagointikykyä ja tuotannon ennustettavuutta. Jos saavutetaan tuotannon nopeutumista ja saadaan vähennetyksi ennakoitavissa olevia häiriöitä, voidaan myös saavuttaa merkittäviä kustannussäästöjä. Lisäksi halutaan saada tukea "tee itse vai osta" -päätöksiin ja lisätä tuotannon ennakoitavuutta, jotta alihankintapäätökset kyettäisiin tekemään riittävän ajoissa. On halvempaa saada alihankintatyövoimaa, jos pystyy tekemään sopimukset ajoissa. Tällöin alihankintojen jäljestäminen kokonaistoimituksiksi on helpompaa.

Simuloimalla halutaan vertailla eri tuotantovaihtoehtojen kannattavuutta ja siten saada aikaan parempi kannattavuus toiminnassa. Simuloinnin avulla pyritään tutkimaan eri tekijöissä tapahtuvien mahdollisten muutosten vaikutusta kokonaisuuteen ja näin valmistautumaan paremmin mahdollisiin poikkeamiin. Näin voidaan tarkastella erilaisia

"mitä tapahtuu, jos muutan tätä arvoa" tilanteita ja tutkia eri tekijöiden riippuvuuksia.

Myös eri resurssien lisäämisen tai vähentämisen vaikutuksia halutaan tarkkailla.

Työn alussa määriteltiin tavoitetila simuloinnin käytöstä, jota havainnollistaa kuva 1-1.

Tavoitetilana oli määritellä malliin linkittyvä tieto ja muodostaa siitä mahdollisimman simulointi ohj elmi stosta riippumaton kuvaus, jota tuotannon suunnittelija pystyy muokkaamaan. Jäijestelmän avulla on tarkoitus saavuttaa projektille asetetut tavoitteet toiminnallisuudesta. Tämän työn tarkoituksena on tutkia kyseisen skenaarion toteuttamiseen tarvittavia tekniikoita.

Tuotannon suunnittelija

I

Suunnittelutieto

Simulointi­

malli

Simulointi- ohjelma Materiaalitieto

Tuotantotieto

Fasiliteetti- tiedot

Kuva 1-1 Tavoitetila simuloinnin käytössä

1.6 Tietojärjestelmien automatisoidut saarekkeet

Laivanrakennuksen nykyiset jäijestelmät ovat huonosti integroituja toisiinsa ja toimivat lähinnä omien erikoisalan sovelluksinaan. CAD-ohjelmien keskinäinen tiedonvaihto onnistuu yksinkertaisissa asioissa kohtalaisesti ja joitakin linkkejä muihin ohjelmiin on yritysten sisällä. Yhteistoiminnassa alihankkijoiden kanssa on ongelmia, koska käytetyt ohjelmat ovat erilaisia. Tämä aiheuttaa paljon paperidokumenttien vaihtoa ja tietojen käsin syöttämistä. Yksityiskohtaisissa simuloinneissa ja tuotannon reaaliaikaiseen hallintaan tarvittavien tietojen haku on toistaiseksi mahdotonta automaattisesti ohjelmallisin keinoin, koska tieto on pirstaleina useassa eri lähteessä. Eri käytössä olevat ohjelmat muodostavat omia automaation saarekkeitaan, kuten kuvassa 1 -2.

Tilaustieto

CAD/CAM

Projektin hallinta ja

aikataulut Materiaalin

käsittely

Kuva 1-2 Automaation saarekkeet

Eri ohjelmien välissä joudutaan kirjoittamaan asioita uudelleen käsin ja muutenkin manuaalisia työvaiheita on paljon. Aikataulutuksessa hiljaisen tiedon ja kokemuksen osuus päätöksenteossa on merkittävä. Tuotannossa aikatauluja seurataan pitkälti tuntiseurarmalle sekä visuaalisella kontrollilla. Materiaalin mukana on tehdaslattialla tunnistetieto, mutta tietoa tietyn osan paikasta ei ole missään järjestelmässä. Tieto tuotannon tilasta on siis visuaalisen kontrollin varassa.

Itse tuotannossa automatisoitujen toimintojen osuus on aika pieni. Tietokoneohjattuja NC- koneita on teräksen leikkaamisessa, vahvisteiden asennuksessa ja taivuttamisessa. Yleisesti ottaen automatisoinnin aste tuotannossa on pieni ja työntekijöiden rooli erittäin suuri. Näin työntekijöiden ominaisuuksilla on olennainen vaikutus ja ammattitaitoisen työvoiman merkitys tuotannossa on suuri. Laivanrakennuksessa, kuten monella muulla alalla, nuorta pätevää työvoimaa on tarjolla aika vähän. Tulevaisuudessa suurten ikäluokkien siirtyessä eläkkeelle tulee tarve lisäautomatisoinnille ja myös monipuolisemmalle koulutusmateriaalille.

1.7 Laivanrakennus ja virtuaaliset yritykset

Virtuaalinen yritys on väliaikainen liitto yksittäisten itsenäisten yritysten välillä, jotka jakavat tietoaan ja resurssejaan pystyäkseen paremmin vastaamaan markkinoiden odotuksiin ja joiden yhteistyötä tukee tietoverkot (Camarinha-Matos, 1997). Muuta luonteenomaista virtuaaliselle yritykselle on, että se vaikuttaa asiakkaalle yhdeltä yritykseltä ja että se kestää vain niin pitkään kuin osallistuvat yritykset saavuttavat näin paremman kannattavuuden kuin toimien itsenäisesti.

Jokainen laivanrakennusproj ekti on eräänlainen virtuaalinen yritys. Telakka toimii yleensä johtavassa asemassa ja kerää ympärilleen projektiin tarvittavat alihankkijat eri

osakokonaisuuksiin. Tämä aiheuttaa luonnollisesti vaatimuksia tiedonsiirrolle projektin eri osapuolien välillä. Tiedon tulee siksi kulkea sekä telakoiden sisällä että alihankkijoiden välillä tehokkaasti.

Laivanrakennusteollisuudessa on virtuaaliyrityksiä tutkittu paljon EU:ssa USA:ssa ja Japanissa. Muun maussa USA:ssa SPARS (Shipbuilding Partners and Suppliers) projekti tähtää telakoiden virtuaaliyritysvalmiuksien parantamiseen käyttäen NIIP teknologioita (National Industrial Information Infrastructure Protocols). Haasteina projekteissa ovat yhteensopimattomat tietojäijestelmät - kuten CAD (suunnittelutieto), PDM (tuotetieto) ja ERP (toiminnanohjaustieto) - tietojen uudelleensyöttöongelmat, rajalliset IT-budjetit ja - resurssit, lyhyet valmistusajat ja pienet eräkoot.

Intemet-teknologioiden nopea kehittyminen on tehnyt virtuaalisten yritysten muodostamisen mahdolliseksi, vaikka parannuksia vielä tarvitaan asioiden helpottamiseksi. Tiedon hallinnan ja liiketoimintaprosessien työkalujen ja menetelmien standardisointi on välttämätöntä, jotta helpompi integraatio tulee mahdolliseksi. Hajautetun simuloinnin lisääntyessä tulee pian mahdolliseksi simuloida myös virtuaalisia yrityksiä.

Suunnittelun tehostumisella ja tuotannon joustavuuden parantumisella voi saavuttaa merkittävää hyötyä.

Sovellusten integroinnissa XML-pohjainen ratkaisu voi tulla kysymykseen. Intemet- teknologioita hyödyntävä käyttöjäijestelmäriippumaton tiedonesitystapa sopisi tiedonvaihtoon sekä yritysten välillä että yritysten sisällä. Tällaisten ratkaisuiden käyttöönotto on suhteellisen edullista. Yhteinen esim. BizTalk (Microsoftin ajama XML- integraatio ratkaisu) tai muu suositun teollisuusstandardin mukainen XML-pohjainen sovelluskieli voisi olla hyvä ratkaisu tiettyihin ongelmiin. Esimerkiksi rakennusteollisuuden tarpeisiin tehty aecXML voisi olla sopiva kommunikointikieli yritysten välillä. Myös tuotetiedon esittämiseksi tarkoitetun STEP-standardiperheen käytön kasvusta hyödyttäisiin.

Virtuaaliyritysten muodostamiseen käytetyt tekniset ratkaisut, simulointien lähtötietojen ja mallien muodostamisen tekniikat ovat lähellä toisiaan. Molempia hyödyttävät standardit ja avoimet rajapinnat järjestelmien välillä.

2 Tuotantoprosessien mallintaminen

Malli on järjestelmästä johdettu määritelmä tietystä näkökulmasta tietyllä abstraktio- ja yksityiskohtatasolla, yksinkertaisemmin malli on kuvaus jostakin. Jotta tuotantoprosesseja voidaan simuloida, ne tulee ensin mallintaa.

2.1 Mallintamistekniikat

Prosessien mallintamiseen on olemassa useita standardeja menetelmiä, jotka mahdollistavat paremman tiedon jakelun ja tiedon uudelleenkäytettävyyden verrattuna epästandardeihin menetelmiin. Jos mallia tulkitaan aina samalla tavalla, tehtyjä malleja voivat hyödyntää muutkin kuin vain mallintaja ja lähipiiri. Standardinmukaisia malleja voi joissain tapauksissa myös suoraan simuloida. Suosittuja ja simuloinnissa sovellettuja

standardeja mallinnustapoja ovat UML ja ШЕР.

Mallien ominaisuuksista uudelleenkäytettävyys on yksi tärkeimmistä. Perinteinen tapa mallintaa suoraan simulointiohjelmistoon on ehkä nopein tapa saada tuloksia, mutta sellaisen mallin uudelleenkäytettävyys on vähäistä ja itse mallien muodostamisessa simulointiohjelmiston vaikutus muodostuu suureksi. Tällöin ollaan riippuvaisia ohjelmiston kehittämisestä ja tuen säilymisestä sekä mallintajasta.

2.1.1 UML

UML tulee sanoista Unified Modeling Language ja se on teollisuusstandardi ohjelmien määrittelyyn, visualisointiin, rakentamiseen ja dokumentointiin. OMG (Object Management Group) hyväksyi sen standardiksi marraskuussa 1997. UML:ä käyttämällä ohjelmoijat ja ohjelmistosuunnittelijat voivat suunnitella ohjelmistoprojektin, mikä helpottaa itse kehitystyötä sekä parantaa dokumentointia. UML kehitettiin yhdistämällä aikaisemmin käytettyjen oliosuuntautuneiden mallinnusmetodologioiden hyviä puolia ja luomalla yksi yhteinen mallinnuskieli, pääasiassa OMI- (Object Modelling Technique) ja OOADA- (Object-Oriented Analysis and Design with Applications) mallinnusmetodologioista (Booch, 2000).

UML kehitettiin mallinnustavaksi liiketoimintaprosesseille, luokkien, objektien, komponenttien ja jakelun mallintamiseen. UML havainnollistaa toisiinsa liittyneet

prosessit ja ohjelma-arkkitehtuurin kaavioilla ja nuolilla, jolloin eri osasten liittyminen toisiinsa saadaan havainnollisemmin kuvattua. UML on standarditapa tehdä tällaisia kaavioita ja tarjoaa siten ohjelmistosuunnittelijoille ja ohjelmoijille yhteisen tavan kommunikoida.

ohjelmistoarkkitehtuurilähtöisesti,

UML-kaavioita käytetään riippuvuuksia

hallintaohj elmissa ohjelmistoprojektien eri osat kulkevat aikajanalla. UML-tuki löytyy hyvin monista, varsinkin objektipohjaisista ohjelmista. Mallinnuksen merkintätapoj en(notaatioiden) ymmärtäminen vaatii jonkin verran asiantuntemusta, joten se ei sinällään sovi kaikille.

kuvaamaan kun esim. projektin

Objektipohjaisten sovellusten kehittäjälle UML on ilmeinen valinta mallintamistavaksi, koska UML on tuetuin ja käytetyin. UML-mallinnusta tukevia ohjelmia on paljon, muun muassa MS Visio ja Rational Rose.

Simulointimallien suunnittelu ja rakennus muistuttaa hyvin paljon ohjelmiston kehitystä, jota varten UML ensisijaisesti kehitettiin. UML-kaavioita on erilaisia eri tarkoituksiin.

Suuri etu on UML kaavioiden toimiminen selkeänä dokumenttina ohjelman toiminnasta, mikä helpottaa ohjelman oikeellisuuden tarkastelua. Hyvä dokumentointi helpottaa toteutettujen komponenttien uudelleenkäyttöä. UML ei ota kantaa ohjelmaan, jolla malli toteutetaan. UML-kaavio voi toimia graafisena konseptien rakenteen sekä dynamiikan kuvaajana simulointimallissa. UML-mallinnuksessa käytettäessä ohjelman dokumentointi tapahtuu samalla sekä mahdollistaa uudelleenkäytettävien komponenttien suunnittelun (Richter, 2000). UML-kaavioita voi käyttää kehittäjän ja käyttäjän välisenä sekä simulointikoodin ja spesifikaation välisenä dokumenttina toiminnasta.

Jos käytössä on ohjelmointitaitoinen simulointien kehittäjä ja objektipohjainen simulointi ohjelmisto, on UML hyvä tapa mallintaa simuloinnin kulkua. Tällöin vaaditaan mallien kommentoijilta hieman opettelua mallien tulkitsemiseen. UML vahvoja puolia on laaja ohjelmistotuki sekä jatkuvasti kasvava osaajien joukko. Tämä mahdollistaa ratkaisuiden pitkäikäisyyden sekä vähentää riippuvuutta yksittäisistä henkilöistä, jotka mallintavat prosesseja. Jos ohjelmistojen kehitys ja ylläpito ovat palveluyhtiöillä on UML:n käyttö erittäin suotavaa, jotta mallin toiminnasta on yrityksessä hyvä dokumentointi. Simuloinnissa kannalta tärkeä tulosten ja mallien validointi, verifiointi ja analyysi helpottuu, koska UML-kaavioiden käyttö helpottaa validointia (mallin

2.1.2 IDEF

IDEF (ICAM DEFinition Language) on standardeihin perustuva mallirmustekniikka, joka kehitettiin alunperin Yhdysvaltojen ilmavoimien projekteissa 1970-luvun alussa

"Integrated Computer Aided Manufacturing"- projektissa (Mäntylä, 2000;

DecisionDynamics, 2001a; Delen, 2000), jonka tavoitteena oli parantaa toimittajien suunnittelu ja tuotantoprosesseja (Mäntylä, 2000). IDEF on oikeastaan kokonainen mallinnusperhe toisiinsa liittyviä malleja (DecisionDynamics, 2001a; Mäntylä, 2000).

Tuotantoprosessien simuloinnin kannalta oleellisimmat IDEF-tekniikat ovat IDEF0 ja EDEF3.

IDEF-mallinnusta on käytetty yritysten toiminnan analysointiin ja uusien toimintatapojen kehittämiseen, prosessien määrittelyyn ja erilaisiin mallinnustehtäviin, esimerkiksi ohjelmistojen kehittämiseen. Yhdysvaltain armeija on edelleen merkittävä mallinnustapojen käyttäjä.

2.1.2.1 IDEFO

Säädöt (rajoitteet) Aloitus ja lopetus aika

Tavoitteet Toleranssit

,r v ^{1 i}

> >

Ottaa sisään:

Syötteet

Tuottaa:

Tuotokset AI

► >

Käyttäen järjestelmiä (resursseja)

Kuva 2-1 IDEFO-malli

IDEFO-mallit ovat toimintopohjaisia, jotka esittävät toiminnot hierarkkisesti. Kuva 2-1 havainnollistaa IDEF-mallin laatikoita. Toiminnot määritellään syöttöjen (input), säätöjen (control), järjestelmien (mechanism) ja tuotosten (output) avulla. Mallinnus tapahtuu suoraviivaisesti sääntöjen perusteella. Lopputuloksena on kaavio prosessin työtehtävistä, josta selviää työvaiheiden järjestys ja hierarkia, mutta joka ei sisällä aikaperusteista tietoa.

Esitysmuotona laatikot ja nuolet kuvaavat prosessien välisiä suhteita ja esittämiseen ja merkintätapoihin liittyvät tietyt säännöt. IDEFO antaa mallintajalle mahdollisuuden esittää sekä korkean tason prosesseja että yksityiskohtaisia toimintoja ja hajottaa ylemmän tason prosessit halutun yksityiskohtaisiin osiin. Laatikot esittävät toimintoja ja nuolet esittävät toimintojen syötteitä (materiaalit, informaatio), tuotoksia (materiaali, informaatio), järjestelmiä (miten toiminto suoritetaan) ja säätöjä (sisäiset ja ulkoiset äärirajat). Esitystapa yksinkertaistettuna on siis, että toiminnon syötteet muutetaan tuotoksiksi järjestelmien avulla. Säätöjen rajoitusehdot otetaan myös huomioon.

Alla kuvassa 2-2 on kuvattu laivanrakennusprosessi telakan kannalta IDEFO-mallina. Se havainnollistaa kokonaistoimituksen muodostumista, jossa materiaaleista tuotetaan valmis laiva.

Aikataulu Suunnitelmat

Toleranssit Säännöt

Materiaalit

Valmis laiva

Kokonaistoimitus

► >

"k Telakka, fasiliteetit, työvoima

Kuva 2-2 Laivanrakennus IDEF -mallina.

IDEFO-mallinnuksen päähyödyiksi on mainittu muun muassa seuraavia asioita (Whitman, 1997; IDEFO, 1993):

• IDEF-prosessikarttojen laatiminen ei vaadi erikoistaitoja ja sitä voivat käyttää kaikki johtajista hitsareihin. Sitä voidaan myös piirtää paperin ja kynän avulla ilman

erikoistyökaluja.

• IDEF-malli helpottaa asioista keskustelua koko organisaatiossa. Nykytilan esitys malli voi toimia lähtökohtana keskusteltaessa tavoiteprosessista. Kaikki mallintajat työskentelevät näin yhteisellä, graafisella ja toimintopohjaisella tavalla ja mallien tulkinta organisaation eri osissa on näin helppoa.

• IDEF-mallia on helppo kommentoida. Monessa tapauksessa helpompi, kuin animaation avulla validointi.

IDEFO-mallinnuksen rajoitteita monimutkaisien tapahtumapohjaisten tuotantoprosessien kuvaamiseen ovat:

• IDEFO käsittelee riippuvuuksia, muttei virtausta; syöte ja tuotos nuolet kuvaavat toimintojen välisiä toimintoja ei todellisten objektien virtausta.

• IDEFO ei kerro aikaperusteisesta käyttäytymisestä. Erityisesti säätöjen ja ohjausten toiminta ja aika eivät tule ilmi.

• IDEFO ei kerro IT arkkitehtuurista eikä tietoa osoitteista, mistä tieto on haettavissa.

• IDEFO-malli tulkitaan helposti toimintosarjaksi, vaikka näin ei aina ole.

2.7.2.2 IDEF3

IDEF3 tarjoaa tavan mallintaa ja dokumentoida prosessien aktiviteettien järjestyksen.

IDEF3:n päätavoite on tarjota erityisalueiden asiantuntijoille hierarkkinen tapa kuvata tietämys tietyn osa-alueen tehtävistä. Tehtävä voi olla uuden tuotteen suunnitteluprosessi yhtä hyvin kuin tehdaslattialla tietyn konepajan toiminta. IDEF3 tarjoaa objektikeskeisen esitystavan prosessille ja kerää yhteen sallitut reitit. Näin esim. voidaan erottaa koko prosessikaaviosta osavalmistuksen osien jäykkäykseen liittyvät vaiheet ja reititysvaihtoehdot. IDEF3 käyttää menetelmiä, jotka poistavat mallin ristiriitaisuudet.

IDEF3 on tarkoitettu nopeuttamaan liiketoimintaprosessien mallinnusta, joka usein alkaa juuri ongelman hahmottamisella. Eri osa-alueiden asiantuntijat voivat ilmaista prosessit sarjoina toimintoja, kuvata eri osasten välisiä suhteita ja käyttäytymistä. Näin päästään kuvaamaan prosessin dynaamista käyttäytymistä.

IDEF3-malli toimii prosessin tiedon tallentajana ja tiedon muokkaus ja laajennus onnistuu.

Metodi on tarkoitettu helppokäyttöiseksi ja hyvin ymmärrettäväksi. UOB- (Unit of Behaviour) laatikoita käytetään IDEF3-mallirmusmetodologiassa. UOB:t kuvaavat aktiviteetin toimintaa ja suhteita muihin toimintoihin. UOB:hen liittyviä käsitteitä ovat tietokannoista ja olio-ohjelmoinnista tutut tyyppi ja instanssi. Tyypillinen prosessi on parasta ajatella kokoelmana aktiviteettilaatikoita (UOB), jotka ovat suhteissa toisiinsa tavalla, joka kuvastaa prosessin kulkua. Jos tarkastellaan kuvan 2-4 maalausprosessia.

Kaavio kuvaa yleisen prosessin, joka alkaa UOB-laatikolla "Maalaa osa", sitä seuraava instanssi on maalin peittävyyden testaus. Sen jälkeen testin lopputuloksen perusteella

prosessi joko palaa "Maalaa osa" instanssiin tai jatkaa "Kuiva osa" instanssiin (Mayer, 1995).

£

Maalaa osa

1 Testaa Kuiva

peittävyys

MEK

^x

Maalaa osa

2

Kuva 2-3 IDEF3-kaavio maalausprosessin työvaiheista.

IDEFO- ja IDEF3-malleja käytetään usein samanaikaisesti analysoitaessa suuria jäijestelmiä kuten lentokoneteollisuuden tuotteita. Tällöin suositellaan aloitettavan ШЕЕ0- mallintamisesta ja siirtyvän IDEF3-mallinnukseen, kun mallin yksityiskohtatasossa päästään objektien liikkumistasolle. Toisaalta yleisesti on parempi aloittaa IDEF3- prosessinkuvauksesta ja sitten erottaa mallista oleellinen IDEFO-malliksi. ШЕРЗ suunniteltiin ottaen nämä mahdollisuudet yhteiskäytöstä huomioon. IDEF3-mallista on tapa viitata IDEFO-mallin toimintoihin IDEF UOB:sta. Kaikissa UOB laatikoissa on kenttä tätä varten. (Mayer, 1995)

UOB Nimi

IDEFO toimintoon Viittaus U

UOB#

Kuva 2-4IDEF3 UOB, jossa viittaus IDEFO malliin.

2.1.2.3 Muut IDEF mallit

IDEF1-mallit ovat suunniteltu tiedon rakenteen kuvaamiseen. IDEF1 määrittelee tarvittavat tiedot, joita tarvitaan kuvaamaan kaikki IDEFO-toiminnot. EDEFlx on laajennettu myöhemmin datan esittämiseen (Mäntylä, 2000). Malleissa data esitetään

ominaisuuksia, jotka kuvaavat olioiden luokkien yhteisiä ominaisuuksia. Avaimet ovat erityisiä olioluokkien attribuuttien tunnisteita. IDEF 1-mallien nykykäyttö on pientä, koska UML tekee samat asiat ja on enemmän käytetty tapa. IDEF2 on dynaaminen malli, joka kuvaa ajassa muuttuvia ominaisarvoja ja on tarkoitettu simulointimallintamiseen.

Kaupalliset ratkaisut ovat kuitenkin paljon enemmän käytössä kuin IDEF2 ja ovat syrjäyttäneet tämän käytön (Whitman, 1997).

2.1.2.4 IDEF ja simulointiohjelmistot

IDEF-malleja on käytetty apuna prosessien mallintamisessa ennen simulointeja. Mallien konvertointi suoraan simulointimalleihin onnistuu osittain. Ongelmia mallien automaattiseen kääntämiseen esiintyy esimerkiksi nuolien vaihtelevien määrien vuoksi.

IDEF-malleihin ei myöskään saada liitetyksi kaikkea simulointeihin tarvittavaa tietoa.

IDEF-mallinnusta tukevia simulointi ohjelmia on muun muassa Meta Software -yrityksen ohjelma WorkFlow Modeler, joka tukee IDEFO- ja IDEF 1 x-mallirmusta. Ohjelman muodostamia malleja voi simuloida saman yhtiön WorkFlow Simulator -ohjelmalla.

Toinen yhdistelmä on mallinnusohjelma Prosim ja simulointiohjelmisto WITNESS.

IDEF3-mallinnusta tukeva mallinnusohjelma Prosim ja WITNESS pystyvät yhteistyöhön siten, että Prosim-mallit voidaan tallentaa suoraan WITNESS-ohjelman käyttämään muotoon. Käännös ei valitettavasti onnistu toiseen suuntaan, jos malliin on lisätty asioita simulointiohj elmistossa (Delen, 12.12.2000).

2.1.2.5 Yhteenveto IDEF-mallinnustapojen käytöstä

IDEF sopii hyvin vain mallintamiseen koska vakavasti otettavien simulaattoreiden IDEF- mallin tulkitsemiskyvyt ovat toistaiseksi vielä varsin heikkoja eikä kaikkea simuloinneissa tarvittavaa tietoa voi sisällyttää IDEF-malleihin. ШЕРЗ prosessimallisena soveltuu simulointeihin ja varsinkin prosessiorientoituvan simulaattorin valinnan yhteydessä.

IDEF-metodologioiden ongelmia on suhteellisen vähäinen ohjelmistotuki sekä sitä kautta vähäinen käyttö. Vaikka IDEF on havainnollinen ja standardi tapa mallintaa ja malleja on suhteellisen helppo tulkita, niin mallinnustavan sääntöjen ja merkintätapojen omaksuminen vie aikaa. Se soveltuu siten paremmin armeijaympäristöön kuin telakoille.

2.1.3 Muut mallinnustavat

Prosessien mallintamiseen voi käyttää myös tavallisia vuokaavioita, joita löytää monista eri ohjelmistoista. Tällaisia mallinnusohjelmistoja vuokaavioiden yms. piirtämiseen on useita ja niitä on monen työntekijän tietokoneissa valmiiksi, jolloin uusien ohjelmistojen ostamista ei tarvita. Yksinkertaisimmillaan prosesseja mallinnetaan MS Office -ohjelman vuokaavio muodoilla, jotka sinällään riittävätkin kuvaan prosessit esimerkiksi kokouksissa.

Voidaan myös käyttää erityistä mallinnusohjelmistoa, kuten MS Visio, joissa useita valmiita mallipohjia. Useat simulointiohj elmien valmistajat ovatkin rakentaneet ohjelmistoonsa yhteyden juuri Visio-ohjelmistoon, jotta saavutetaan helpompi mallien rakentaminen.

Hyötyjä ei-standardin mallintamisen käytössä on helppous, nopeus ja hinta. Ongelmana on, että koska kaikki voivat tehdä asioita omalla tavallaan, niin mallien tulkinta ei ole yksiselitteistä. Tällöin ongelmia mallien oikeellisuuden tarkastamisessa syntyy helpommin.

Simuloinnin antamien tuloksien oikeellisuutta ja luotettavuutta tarkistettaessa mallin toiminta korostuu. Ei standardin mallin läpikäyminen on ongelmatilanteissa hitaampaa ja säästetty aika mallintamisessa menetetään helposti tarkistamiseen. Myös vanhojen mallien käyttö uusissa projekteissa on tällöin hankalampaa.

2.1.4 Suositukset mallintamistekniikoista

Koska suosituksien simulointiohjelmistot perustuvat enemmän oliopohjaisiin ratkaisuihin, on UML varmasti sopivin tekniikka mallien logiikan tallentamiseen ja toteutettujen simulointimallien dokumentoimiseen. Mallien kehitysvaiheessa eri alojen asiantuntijoilta prosessiasioiden suunnittelun yhteydessä voi varmasti käyttää vähemmän standardeja menetelmiä, koska itse simulointimalli voidaan kuitenkin dokumentoida standardilla tavalla. Tällöin riittää simulointi asiantuntijan riittävä osaaminen UML:stä.

Ei ole syytä olettaa, että useat ihmiset opettelisivat käyttämään mitään metodeita täysin oikein, mutta hyviä puolia eri tavoista kannattaa yhdistää malleja muodostettaessa ja käyttää näin hyödykseen esim. IDEFO-tyyppisiä laatikoita ja perussääntöjä merkinnöille alustavan mallin rakentamisen vaiheissa. Tästä voi sitten rakentaa simulointiohj elmi stoon

saadaan malliin oikein. Tällöin siis riittäisi, että telakoilla simuloinnista vastuullinen henkilö ymmärtäisi ja auttavasti piirtäisi UML:n mukaisia kaavioita.

2.2 Tekniikat tiedonsiirtoon

2.2.1 STEP

STEP (ISO 10303) on kokoelma tuotetiedon esittämisen standardeja eli STEP AP:ta (Application Protocols). AP:t ovat yhteisiä sovelluskäytäntöjä, jotka sisältävät STEP- tietoformaatin, EXPRESS-tiedonkuvauskielen sekä yhteiset määritelmät eri resurssien nimeämiselle. STEP lyhenne tulee englannin sanoista International Standard for the Exchange of Product Model Data eli kansainvälinen standardi tuotemallitiedon välitykseen. Laivanrakennusteollisuudelle tähdättyjä STEP-malleja on kehitelty eri puolilla, mm. EU:n Seasprite-, Yhdysvaltain MariSTEP- sekä Korean ShipSTEP- ohjelmissa. Ohjelmissa on tehty yhteisiä standardeja tuotetiedon esittämiseksi. STEP- ponnisteluiden tavoitteena on taijota järjestelmä, joka pystyy kuvaamaan tuotetietoa läpi tuotteen elinkaaren järjestelmäriippumattomasti. Kuvaus mahdollistaa riippumattomien tiedostojen vaihtamisen sekä jaetut tuotetietokannat ja arkistoinnin. STEPin eri AP:t määrittelevät yksittäisen STEP-muotoisen sovelluskohteen tiedonesitystavan.

Laivanrakennukseen suunnattuja STEP AP:a ovat: Laivan luokitus (AP215), laivan valetut muodot (AP216), laivan putkitukset (AP217), laivan rakenne (AP218), laivan mekaaniset järjestelmät (AP226) sekä laivan käytön lokitiedot, tallennukset ja viestit (AP234).

Laivanrakennusteollisuus on jäljessä esim. lentokone- ja autoteollisuutta STEP:in hyödyntämisessä. Toisaalta siellä kehitetyt STEP AP:t ovat käyttökelpoisia myös laivanrakennusteollisuudessa. Esimerkiksi AP203 sopii geometriatiedon siirtoon ja AP209 on käyttökelpoinen suunnittelutiedon vaihdossa (Systems technology panel, 2000).

Esimerkiksi BMW:llä on tietokannoissaan CAD-malleja autoistaan kymmeniä gigabittien määrä CATIAn tiedostoformaatissa. Niiden kääntäminen uuteen CAD-formaattiin ei ole käytännöllistä tai edes haluttavaa. BMW:n tapauksessa STEP konvertointia pidetään parhaana vaihtoehtona, jotta tietoja päästään etsimään ja tarvittaessa konvertoimaan uuteen versioon. (Mäntylä, 49, 2000)

Potentiaalisia hyötyjä STEPin käytössä ovat nopeammat suunnitteluajat, tehostunut tietojenvaihto eri osapuolten välillä sekä pitempään käytettävissä oleva tieto. Nämä asiat

voidaan saavuttaa, koska STEP tukee suunnittelutiedon uudelleenkäyttöä, tiedon säilyttämistä ja pääsyä tietoon koko tuotteen elinkaaren aikana. Tehokas tiedonvaihto ja säilytys tukevat rinnakkaista suunnittelua, järjestelmäintegraatiota, sähköistä kaupankäyntiä ja laadunhallintaa. STEPin käytön tavoitteina on saada tilaus-toimitusketju nopeammaksi ja joustavammaksi, kokonaiskustannukset pienemmiksi, laatu paremmaksi sekä mahdollistaa tietojen uudelleenkäytettävyys.

STEPin käyttämiseksi tarvitaan STEPiä tukevia työkaluja suunnittelun käyttöön sekä alihankkijoille. Tämä ei ole välttämättä nopea prosessi, koska IT-investoinnit eivät ole kovin isoja laivanrakennusteollisuuden yrityksissä. STEPin haittana on työkalujen vähyys ja käytön suhteellinen vaikeus. Tämän vuoksi on kehitteillä STEP/XML-käännöksiä, jotka mahdollistavat tietojen siirron XML-muotoiseksi, jolloin sekä jakelu ja katselu olisi erittäin helppoa intemet-tekniikoiden avulla. Tekniikka STEP-datan siirtämiseen käyttäen XML- muotoon on kuvattu standardissa ISO 10303-28, joka on EXPRESS-skeeman ja tiedon kuvaus XML-muotoisena.

2.2.2 XML

XML on tuonut internetiin uuden yleiskielen informaation tallentamiseen ja jakamiseen.

Yhteinen standardi on tehokkaalle tietojenvälitykselle ehdoton edellytys. XML yksin ei takaa vaivatonta tiedonsiirtoa eikä käytettävyyttä, mutta XML-muotoisen yhteisen sovelluskielen luominen on mahdollista ja työkaluja on useita XML-muotoisten dokumenttinen käsittelyyn. Semantiikasta ja rakenteesta täytyy sopia yhdessä XML- sovelluskieltä luotaessa. Yhteinen XML-kielioppi mahdollistaa informaation vaihdon yritysten välillä edullisesti ja helposti intemet-teknologiaa hyödyntäen.

XML (extensible Mark-up Language) kehitettiin pääasiassa SGMLm pohjalta ajatuksena luoda yksinkertaisempi kieli kuin SGML, joka olisi kuitenkin laajennettavissa eri sovellusalueisiin. Kun SGML:stä paljon yksinkertaistettu HTML suunniteltiin www-sivuja varten, niin XML suunniteltiin kuvaamaan ja välittämään rakenteista tietoa internetissä.

XML suunniteltiin ennen kaikkea www-sivuihin, kirjallisuuteen, käyttöohjeisiin, sopimuksiin ja vastaaviin sovelluksiin, joita ihmiset lukevat. Suuri kasvu XML:n käytössä

XML on metakieli, runko muiden kielien kuvaamiseksi. Kieltä määriteltäessä valitaan ensin käytetyt elementit, joille voidaan antaa omat kuvaavat nimet. XML kuvaa, kuinka kuvaukset pitää rakentaa. XML LO on internet teknologioiden standardointia ajavan W3C:n suositus helmikuulta 1998 (Bray, 1998). Nuoreksi teollisuusstandardiksi XML on kypsää tekniikkaa, koska sen kehittelyä ei luotu tyhjästä. Suosituksesta on toinen painos W3C:n suositus lokakuu 2000, jonka ainoat muutoksen alkuperäiseen olivat virheiden korjaaminen (Bray, 6.10.2000).

Vaikka käyttää XML:ä tiedonvälitykseen, on standardointi tarpeellista. Jotta XML:ä voidaan käyttää laajassa mittakaavassa, tulee sopia yhteisistä kieliopista tiedon merkitsemiseen. Jos toinen käyttää <osan_numero> merkintää ja toinen käyttää

<osa_numero> merkintää, ei ohjelmallisesti lukeminen suoraan onnistu ilman muokkaamista, vaikka se ihmissilmälle ei tuottaisi mitään ongelmia.

Sovellusten välinen yhteistoiminta on yksi tärkeimmistä haasteista laivanrakennusteollisuudelle ja XML tarjoaa mahdollisuuden todella merkittäviin parannuksiin tällä alueella. XML:ä voi käyttää järjestelmien välisessä toiminnassa tuote- ja prosessi-informaation välitykseen. USA:ssa on kehitetty laivanrakennusteollisuuden tarpeisiin referenssiarkkitehtuuri ISE-projektissa, jotta tiedonjakaminen helpottuu.

(Systems Technology Panel, 2000). ISE-projektissa käytetään STEPiä ja XML:ä laivanrakennukseen sopivia sovellutuksien käyttöönotossa muun muassa:

• Osaluetteloiden tiedonhallintaan eri yrityksissä.

• Putkistojen toiminnallisuuden suunnittelutietojen, kaaviokuvien ja putkistosimulointien väliseen yhteistoimintaan.

• PDM-tiedon välitykseen yritysten välillä.

• PDM- ja CAD-työkalujen väliseen yhteistoimintaan eri yritysten välillä.

• Putki-CAD ja putkikuormitusanalyysissä käytettävien järjestelmien yhteistoiminnassa.

• Rakenne- j a putkitustiedon yhteistoimintaan.

ISE on määritellyt STEP-tiedon ja XML-työkalujen yhteistoimintaa siten, että luodaan perusta Yhdysvaltain laivanrakennusteollisuuden sisäiseen sovellustenväliseen yhteistoimintaan. XML:n omaksuminen joka puolella saadaan suuria etuja, koska tekniikoiden kehittyminen on nopeata ja työkaluja on paljon. XML on tämän hetken "state- of-the-art"-ratkaisu erilaisissa IT-integraatioasioissa ja erityisen sovelias tiedonsiirtoon

alihankkijoiden ja asiakkaiden kanssa, koska pystyy hyödyntämään olemassa olevia intemet-teknologioita.

2.2.3 Muut tekniikat

Erilaisia pyrkimyksiä on standardien prosessinkuvauskielien tekemiseen prosessitiedon tiedonsiirtoon eri järjestelmien välillä. Yksi esimerkki tällaisesta on PSL (Process Specification Language), joka pyrkii luomaan tavan kuvata valmistusprosesseja. PSL:n tavoite on olla tapahtumapohjaiselle valmistusprosessit!edolle sama, kuin mitä STEP on tuotetiedolle. Toistaiseksi standardointiprosessi on vielä kesken ja käyttö ei vielä ole yleistynyt. Yleistyessään PSL:stä olisi paljon hyötyä simuloinnin yleistymiselle, koska se on suunniteltu kuvaamaan mm. tuotannon aikaiauluttamista, tuotannon suunnittelua, prosessien suunnittelua, workflowrta, simulointia ja projektin johtamista. Hankkeen takana on USA:n NIST. Lisätietoa projektista on osoitteessa: http://www.mel.nist.gov/psl/.

2.3 Rakennustapasuunnitelman muoto

Lohkojen simulointi perustuu pitkälti rakennustapasuunnitelman sisältämään tietoon, joka nivoo yhteen projektin aikataulun ja tuotantoresurssit. Rakennustapasuunnitelmat ovat olleet telakoilla suhteellisen vapaamuotoisia Word-dokumentteja, joihin on lisätty upottamalla tai liitteinä CAD-kuvia. Kyseinen dokumentti on sitten kierrätetty asianomaisille henkilöille sisäisenä jakeluna. Kovin montaa uutta versiota ei ole tehty, koska kommentointi ja jakelu on hidasta ja eri vaihtoehtojen tarkasteluun kuluu paljon aikaa. Kun rakennussuunnitelma on valmis, on myös suurin osa kustannuksista lyöty lukkoon ja mahdollisuus vaikuttaa aikatauluihin on vähäistä.

Simuloinnit tarvitsevat lähtötietoina lohkojen ja osavalmistuksen eri työvaiheiden jaksotuksia ja kestoja. Niiden ja materiaalitietojen perusteella pystytään muodostamaan eri osaprosessien aikataulut, joiden toteutumista voitaisiin simuloinnilla testata. Tarvittavat lohkojen kääntämiset ja eri työvaihein jaksotukset kuuluvat rakennustapasuunnitelmaan.

Tämä tieto on hyvä saada integroiduksi automaattisesti simulointimalliin, koska toinen vaihtoehto eli simuloijan käsin lähtötietojen syöttäminen on aina uusi mahdollisuus tehdä

tiedon syöttö tehdään mahdollisimman helpoksi esim. muodostamalla simulointia varten valmis pohja perusrakennustapasuunnitelmien tiedon syöttämiseksi malliin.

2.4 Tietolähteet

Simuloinnissa tarvittavaa lähtötietoa voi jakaa eri ryhmiin. On tuotekohtaista tietoa, kuten tietoa osista, niiden määristä ja ominaisuuksista. Tuotantotietoa ovat reititykset, sijoittelu, työvuorot ja resurssien jakaminen eri työvaiheisiin. Tieto voidaan jakaa myös simuloinnin kannalta tietoon, jonka kerääminen saadaan automaattisesti olemissa olevasta tietojärjestelmistä sekä tietoon, jota täytyy kerätä simulointia varten.

Malliin tarvittavia tietoja kerätään (Verbraech, 2000a):

1. Historiatiedoista (olemassa olevista lähteistä).

2. Kohteen asiantuntijoilta (osaavat arvioida).

3. Mittauksista (aikaa vievää).

4. Vastaavista järjestelmistä (käytetään tunnetun samantapaisesti käyttäytyvän järjestelmän tietoja hyväksi).

5. Laitteiden valmista) ien antamaa tietoa.

Jos halutaan tutkia eri layout-vaihtoehtoja ja uusien esim. hitsausrobottien hankintaa, niin silloin voidaan käyttää myös valmistajan antamaa tietoa. Kaikki tieto kannattaa tarkastuttaa ja pitää mielessä "Roskaa sisään - Roskaa ulos" -periaate. Mallinnettavan prosessin asiantuntijoita kannattaa käyttää tarkistamaan kerätty tieto historiatiedoista, mittauksista ja laitevalmistajilta.

Työntekijöiltä kysyttäessä ongelmia voi olla, koska

• Vastaajat eivät ymmärrä projektin luonnetta.

• Vastaukset voivat olla asenteellisia tai yksipuolisia.

• Työntekijöiden vähäinen motivaatio tiedon keräämiseen aiheuttaa tietojen laadun heikkoutta.

• Tärkeät harvemmin suoritettavat tehtävät voivat j äädä kertomatta.

Masa-Yardsilla tehdyissä simuloinneissa yksi ongelma oli juuri tiedon keräämisessä.

Mallia varten kerättiin tietoa seurantakansioilla, joiden täyttäminen oli työntekijöiden

vastuulla. Tavoitteena oli saada tieto työvaiheiden todellisista kestoista, mutta seuranta epäonnistui, koska melkein puolet otokseen sisällytetyistä paneeleista oli vääränlaisia ja henkilökunta ei sisäistänyt seurannan tärkeyttä, osa jopa laiminlöi tiedon keruun (Leino, 81-83, 1998). Tuloksena oli, että mallia ei saatu luotettavaan kuntoon kyseisen diplomityön aikana.

Tiedonkeräämisessä tulee keskittää ponnistelut oikeisiin kohtiin eli muuttujiin, joiden merkitys läpimenoon on suurin. Tietoa tulee olla erityisesti usein käytetyistä komponenteista, kuten tyypillisten tyyppilohkojen läpimenoajoista riittävällä tarkkuudella.

Aluksi voi varmasti aloittaa epämääräisemmällä tiedolla, jota voidaan sitten tarkentaa. Jos tuotannossa joudutaan suorittamaan mittauksia, niin tämä kannattaa tehdä hyvin kohdistetusti ja muistaa motivoida ja ohjeistaa tiedonkerääjät riittävän hyvin. Tarvittaessa kannattaa hyödyntää ohjelmia, kuten ExpertFit, apuna, kun oma tilastotieto puuttuu.

Näiden ohjelmistojen ominaisuuksia on avustaa lähtötiedon jakaumien määrittelyssä sekä puuttuvan tiedon arvioimisessa.

Turun telakalla käytössä oleva sovellus lohkojen sijoitteluun on hyvä esimerkki hyvin toimivasta tiedonkeruusta. Siellä työnjohtajat päivittävät oman kohteensa tiedot ja tieto tuotannon nykytilasta on aina saatavilla. Turvallisuus asiat on hoidettu siten, että yksittäiset käyttäjät pääsevät muuttamaan vain määrättyjä tietoja ja järjestelmä rekisteröi käytön.

2.5 Mallin yksityiskohtataso

Mallin yksityiskohtataso on parasta mahdollisimman vähäinen, joka silti riittää tarkasteltavan ongelman tavoitteiden saavuttamiseen. Tyypillisesti malleissa toimii 20/80 sääntö. Eli 20% muuttujista määrää 80% järjestelmän käyttäytymisestä. Kannattaa siis mallintaa vain oleellisin ja merkittävin osa. Kuva 2-4 havainnollistaa tätä.

Yksityiskohtatasoa mietittäessä aina kannattaa pitää mielessä kysymys: Tarvitsenko tätä tietoa?

80%

Simulointimallin yksityiskohtataso

Kuva 2-5 Yksityiskohtatason vaikutus tulosten luotettavuuteen

Yksityiskohtatason lisääminen lisää luotettavuutta, mutta samalla myös kustannuksia. Mitä enemmän muuttujia, sitä enemmän simulointimallin tekemiseen ja käyttämiseen kuluu aikaa. Itse asiassa liian suuri yksityiskohtataso voi aiheuttaa ongelmia myös tulosten luotettavuuden arvioinnissa, koska tällöin oleellisten riippuvuuksien huomaaminen vaikeutuu. Mittausten suuri määrä aiheuttaa myös suuremmat kustannukset tiedonkeruussa ja voi johtaa käytöstä luopumiseen. Parempi siis aloittaa pienemmästä yksityiskohtatasosta ja tarkentaa kohdistetusti paikoista, joiden käyttäytyminen tulee tuntea paremmin.

Operatiivisessa käytössä voidaan seurata jatkuvasti simuloinnin ennustamia ja toteutuneita arvoja. Jos tällöin huomataan ongelmia, niin voidaan ongelmakohtia tarkkailla kohdistetusti tarkemmin ja tarvittaessa lisätä yksityiskohtatasoa.

2.6 Komponenttien ja mallikirjaston luominen

Simulointimalliin halutaan luoda omista tuotannontekijöistä komponentit ja tallentaa ne oman prosessin mallikiijastoksi, koska tavoitteena on mahdollisimman todenmukaiset simuloinnit. Komponentteja on siis esimerkiksi mallit todellisista koneista ja laitteista, työryhmistä ja tehdaskalenterista. Eri komponentteihin halutaan liittää omat ominaisuudet, joten esimerkiksi ensisijaisen miehityksen tuottavuus voi poiketa kolmosmiehityksestä.

Koska tavoitteena on mallien uudelleenkäytettävyys, on tärkeää suunnitella käytetyt komponentit tarkkaan. Komponenttien muuttujista halutaan erotella usein ja harvemmin

s>o'O

cm

(f lC C C O l^ ^ C D ^ O C r"

muokattavat arvot. Mallikirjaston luomisessa tärkeää on suunnitella mallin rakennuspalikat osana järjestelmää. Komponenttien mallinnus kannattaa aloittaa joko alhaalta ylös tyyliin tai keskeltä laajentaen (Verbraech, 2000c). Standardointi, iterointi ja eri vaihtoehtojen tarkastelu tulee pitää mielessä suunniteltaessa eri objektien keskinäisiä kytkentöjä.

Ymmärrettävyyden ja yksinkertaisuuden saavuttamiseksi kannattaa minimoida yksittäisen objektin ominaisuuksia ja toimintoja. Mallikirjaston dokumentointi on kannattaa myös tehdä huolellisesti, jotta myöhemmin muutosten tekeminen on helppoa.

3 Tuotantoprosessien simulointi

3.1 Yleistä tuotannon simuloinnista

Simuloinnissa testataan mallin avulla jäijestelmän käyttäytymistä eri tilanteissa ja malli siis jäljittelee todellisen jäijestelmän käyttäytymistä. Simulointimalleja käytetään paljon muun muassa koulutuskäytössä ja uusien prosessien suunnittelussa. Simulointi on oikean prosessin mallintamista ja kokeiden tekemistä tällä mallilla. Tarkoituksena voi olla jäijestelmän toiminnan ymmärtäminen, tai eri strategioiden arviointi (tiettyjen

määriteltyjen kriteerien perusteella) jäijestelmän käyttämisestä.

Simulointi on tuotannossa usein ongelmanratkaisumetodologia reaalimaailman ongelmien ratkaisemiseksi. Simulointia käytetään kuvaamaan ja analysoimaan jäijestelmän käyttäytymistä tarkastelemalla eri "mitä - jos" -skenaarioilla (mitä tapahtuu, jos muutan tätä arvoa) ja sitä käytetään apuna suunnittelussa. Simulointia voidaan käyttää sekä olemassa olevien jäijestelmien että suunnittelupöydällä olevien mallien tarkasteluun.

Aikaisemmin riitti, että saatiin simuloinnin prosessikuvaukset sellaiseksi, että mallin tulokset kuvasivat todellisuutta, jonka jälkeen etsittiin parannuskohteita. Nyt pyritään kuvaamaan prosessit käyttäen todellista dataa tietojäijestelmistä ja simulointia käytetään myös operatiivisena työkaluna, jonka toiminnan validointi suoritetaan reaaliaikaisesti toteutuneen perusteella. (Verbraech, 2001)

Tapahtumapohjaista simulointia on perinteisesti pidetty projektiluonteisena.

Simulointimalli on rakennettu tukemaan analysointia ja ennustamaan monimutkaisten jäijestelmien suorituskykyä ja auttamaan valitsemaan paras vaihtoehto muutamasta, hyvin määritellystä vaihtoehdosta. Tyypillisesti tällaiset simulointiprojektit ovat aikaa vieviä ja kalliita ja perustuvat simuloijien ja konsulttien ammattitaitoon. Mallit ovat tällöin tuottaneet kertakäyttöisiä malleja, joiden käyttö on rajoittunut spesifiseen tarkasteluun.

Tyypillinen esimerkki on tehtaan layout-ratkaisun uudelleensuunnittelu. Kun päätös uudesta layoutista on tehty, niin simulointimalli on tehnyt tehtävänsä, koska mallista saatavat tulokset ovat rajoittuneet vain parhaan layoutin määrittämiseen käytetyistä olettamuksista.

Simuloinnin käyttö myös operatiiviseen tuotannonsuunnittelukäyttöön on lisääntynyt. Tätä varten on tehty käyttöliittymiä muun muassa taulukkolaskentaohjelmiin. Erillisellä

käyttöliittymällä mallien käyttö ja hallinta helpottuu. Tulevaisuudessa koko simulointimallin muodostaminen ja käyttäminen voi tapahtua esimerkiksi tavallisella selaimella mistä tahansa ja käyttäjän ei tarvitse edes tietää, että kyse on simuloinnista.

Simulointi sulautuu yrityksen muihin jäijestelmiin toimien yhtenä komponenttina kokonaisuudessa. (Harrell, 1998)

Normaalin simulointiproj ektin eteneminen esitetään kuvassa 3-1. Tämä on perinteinen tapa simuloida, jolloin kaikki tehdään alusta loppuun ja uudelleenkäytettävyyttä ei juuri mietitä.

Operatiivisessa käytössä on simuloinnin loppukäyttäjälle kokeilujen suunnittelu, ajot ja analyysit sekä tulosten raportointi korostuu. Toki myös lähtötietojen keruu, mallien verifiointi ja validointi ovat tärkeitä osia, mutta ne voidaan tehdä valmiiksi käytetyille komponenteille simulointiobjektikiijastojen rakentamisen yhteydessä.

Ongelman

muodostaminen Kokeilujen

suunnittelu

1f

Proj ekti suunnitelma

v Tuotanto ajot

ja analyysit Mallin

rakentaminen

r* Tiedon keruu ^M—

Kyllä 11 Kyllä

Lisää testiaj oj a

* Ohjelmointi

' r Ei

Ei

Verifiointi?

Ohjelman dokumentointi j a tul osten raportointi Kyllä

Ei Ei

Validointi? 1 1

{^^Käyttö ö nottcP^}

Kyllä

Kuva 3-1 Simulointiproj ektin eteneminen