Anomaliatunnistus EdgeAI-laitteelle - Tekninen Dokumentaatio

Sisällysluettelo

1. Yleiskatsaus

Tämä dokumentti kuvaa EdgeAI-projektin anomaliatunnistusratkaisun (poikkeamien tunnistus) toteutuksen ja ML-prosessin. Ratkaisu tunnistaa poikkeavat mittauspisteet servon liikeradan sensoridatasta käyttäen IsolationForest-mallia (scikit-learn), ja se on suunniteltu toimimaan ilman erillistä poikkeamalabelointia (unsupervised).

1.1 Tavoitteet

1.2 Määritelmät

1.3 Teknologiapino

Projektin toteutuksen lähde

Tämän dokumentin tekniset yksityiskohdat vastaavat ML-kansion toteutusta:

  • ML/anomalydetect.ipynb
  • ML/generate_graphs.py
  • ML/feature_order.json
  • ML/anomaly_model.pkl ja ML/feature_scaler.pkl

2. ML-putken arkkitehtuuri

Ratkaisu noudattaa selkeää ML-putkea (data → feature engineering → skaalain → malli → scoring/päätös). Lisäksi tuotetaan dokumentointia tukevat kuvat valmiiksi.

2.1 Prosessin vaiheet

  1. Datan keräys: mittausajot JSON-muodossa (data/*.json)
  2. Rakennepurku: acceleration-kenttä normalisoidaan sarakkeiksi
  3. Feature engineering: derivaatat ja liukuvat tilastot
  4. Train/test-jako: ajokertapohjainen jako (kokonaiset ajot erilleen)
  5. Esikäsittely: StandardScaler fit vain train-dataan
  6. Mallinnus: IsolationForest (unsupervised)
  7. Scoring ja päätös: decision_function + predict
  8. Artefaktit: mallin, skaalainerin ja feature-järjestyksen tallennus
  9. Dokumentointikuvat: valmiit kuvat (../images/*.png)

Koneoppimisen parhaat käytännöt

Järjestelmä noudattaa koneoppimisen parhaita käytäntöjä:

  • Train/test-jako estää ylisovittamisen
  • Data leakagen välttäminen (scaler fitataan vain train-dataan)
  • Reproducibility: random_state ja tallennetut artefaktit
  • Tuotantoyhteensopivuus: feature-järjestys tallennetaan (feature_order.json)

3. Data, laatu ja esikäsittely

3.1 Datan lähde

Sensoridata kerätään Servon liikeradan mittaus -laitteelta ja tallennetaan JSON-muotoon. Jokainen tiedosto sisältää yhden mittausajon. Tässä dataa on kerätty yhdeksän mittausjakson ajalta (9 ajokertaa). Kussakin ajokerrassa on tyypillisesti 54 mittausta (yhteensä 486 datapistettä).

Huomio datamäärästä

Nykyinen datasetti on pieni. Tämä on riittävä prototypointiin ja end-to-end -putken todentamiseen, mutta tuotantokäyttöön suositellaan lisää dataa eri olosuhteista (kuorma, lämpötila, mekaaninen kuluma, kiinnitykset) sekä mielellään myös poikkeamien manuaalista validointia.

{
  "measurements": [
    {
      "time_ms": 0,
      "angle": 0,
      "acceleration": {
        "x": 2032,
        "y": 1991,
        "z": 1638,
        "total": 3282
      }
    },
    ...
  ]
}

3.2 Feature Engineering

Raakadatasta luodaan seuraavat featuret. Feature-järjestys on kriittinen ja vastaa tiedostoa ML/feature_order.json.

Feature Kuvaus Tarkoitus
angle Kulma (asteina) Laitteen asento
acc_x, acc_y, acc_z Kiihtyvyys akselittain 3D-liikkeen analyysi
acc_total Kokonaiskiihtyvyys Yleinen liike
d_angle Kulman derivaatta Äkilliset käännökset
d_acc_total Kiihtyvyyden derivaatta Äkilliset kiihtyvyyden muutokset
acc_total_ma Liukuva keskiarvo (5) Trendien tasoitus
acc_total_std Liukuva std (5) Värinän tunnistus

3.3 Train/test-jako (ajokertataso)

Train/test-jako tehdään ajokertojen perusteella, jotta testijoukossa on kokonaisia mittausajoja, joita ei ole nähty koulutuksessa. Tämä on tärkeää erityisesti aikasarjamuotoisessa datassa ja vähentää data leakagen riskiä.

3.4 Skaalaus (StandardScaler)

Kaikki featuret skaalataan StandardScaler-muunnoksella. Skaalain fitataan vain train-dataan ja samaa muunnosta käytetään testiin ja tuotantoon.

Datan laatu

Varmista että:

  • Datan aikaleimat ovat johdonmukaisia
  • Ei ole puuttuvia arvoja
  • Kaikki mittausajot ovat samanpituisia
  • Sensorien yksiköt ja mittausskaalat pysyvät vakioina (muuten score-jakauma driftää)

4. Mallinnus ja koulutus

4.1 Isolation Forest

Isolation Forest on tehokas anomaliatunnistusalgoritmi, joka:

4.2 Mitä malli tuottaa

4.2 Parametrit

iso_forest = IsolationForest(
    n_estimators=100,      # Puiden määrä
    contamination=0.05,    # Oletus poikkeamien osuudeksi
    random_state=42,       # Reproducibility
    n_jobs=-1              # Rinnakkaisuus
)

4.3 Train/Test-jako

Data jaetaan ajokertojen perusteella:

Scaler fitataan VAIN train-dataan ja käytetään samaa skaalaineria test-datalle. Tämä estää data leakagen.

4.4 Reproducibility ja determinismi

5. Evaluointi

5.1 Metriikat

Train Data

5.0%

Poikkeamien osuus

Test Data

1.9%

Poikkeamien osuus

Yleistymiskyky

3.1%

Ero prosenttiyksikköinä

Mitä nämä luvut tarkoittavat tässä ratkaisussa?

Tässä projektissa käytössä on IsolationForest ilman ground truth -labeleita. Tällöin “metriikat” ovat ensisijaisesti käyttökelpoisuus- ja stabiilisuusmittareita (eivät lopullisia laatumittareita kuten precision/recall).

  • Train Data 5.0%: Mallin contamination=0.05 ohjaa päätösrajaa niin, että train-datasta noin 5% pisteistä luokitellaan poikkeamiksi. Tämä on odotettu tulos, eli se kertoo ennen kaikkea että malli toimii teknisesti oikein.
  • Test Data 1.9%: Poikkeamien osuus uudessa datassa samalla mallilla ja samalla skaalauksella. Jos test-datan “normaali käyttäytyminen” on sama kuin trainissa, osuuksien tulisi yleensä olla melko lähellä toisiaan.
  • Yleistymiskyky 3.1%-yks.: Erotus train vs test -anomaliaosuudessa. Tämä on nopea signaali siitä, onko data- tai prosessimuutoksia (drift) tai onko datasetti pieni/epästabiili.

Tärkeä huomio: “Vähemmän poikkeamia testissä” ei automaattisesti tarkoita parempaa mallia. Se voi tarkoittaa myös sitä, että testiajot ovat erilaisia (tai datasetti on pieni), jolloin päätösrajan tulkinta muuttuu.

Evaluointi ilman ground truth -labeleita

Koska kyseessä on unsupervised-anomaliatunnistus, perinteiset luokittelumetriikat (precision/recall) eivät ole käytettävissä ilman labelointia. Tämän vuoksi evaluointi keskittyy:

  • Stabiiliuteen: score-jakaumien ja poikkeamaprosentin vertailu train vs test.
  • Järkevyyteen: poikkeamien sijoittuminen ajassa ja ajokerroissa.
  • Selitettävyyteen: feature-korrelaatiot scoreen (suuntaa-antava analytiikka).

Kun tuotannossa halutaan mitata “todellista laatua”, tarvitaan vähintään: (1) poikkeamien manuaalinen validointi otokselle tai (2) heuristiikka/konfiguroitu sääntö, joka määrittelee mitkä tapahtumat ovat oikeita vikoja.

5.2 Visualisointi

Järjestelmä tuottaa seuraavat visualisoinnit:

Miksi visualisointeja tarvitaan?

Unsupervised-anomaliatunnistuksessa visualisoinnit ovat käytännössä tärkein tapa varmistaa, että malli tekee järkeviä päätöksiä: nähdään miten score käyttäytyy, milloin poikkeamat syntyvät ja minkä tyyppisiin signaalimuutoksiin malli reagoi.

5.2.1 Anomaly Score Jakauma

Train ja test -datojen anomaly score jakaumat näyttävät, kuinka malli pisteyttää eri datapisteitä:

Anomaly Score Distribution

Miten tulkita:

5.2.2 Anomaly Score ajan funktiona

Keskiarvoistettu anomaly score ajansuhteen näyttää systemaattiset muutokset mittauksen aikana:

Anomaly Score Over Time

Miten tulkita:

5.2.3 Featurejen Korrelaatiot

Featurejen korrelaatiot anomaly scoreen näyttävät mitkä ominaisuudet vaikuttavat eniten poikkeamien tunnistukseen:

Feature Correlations

Miten tulkita:

5.2.4 Poikkeamat 2D-projektiossa

2D-projektio kulman ja kokonaiskiihtyvyyden avulla visualisoi poikkeamien sijoittumista:

Anomaly Scatter 2D

Miten tulkita:

5.2.5 Poikkeamien Määrä per Ajokerta

Poikkeamien määrä eri ajokerrissa näyttää vaihtelua mittausajojen välillä:

Anomaly Counts per Run

Miten tulkita:

5.3 Tulosten tulkinta

Mitä voit päätellä näistä tuloksista (ja mitä et)

  • Voit päätellä: Onko score-käyttäytyminen stabiilia, löytyykö poikkeamia tietyistä liikkeen vaiheista, ja onko datassa ajokertakohtaista vaihtelua.
  • Et voi päätellä: Todellista “vikatunnistuksen tarkkuutta” ilman labelointia tai muuta totuusdataa.

Käytännön tulkinta ja suositus

Hälytyksen muodostaminen (suositus)

Yksittäinen poikkeamapiste ei yleensä ole riittävä hälytysperuste. Tyypillisesti parempi on:

Nykyisen datan tulkinta

Testissä havaitaan vähemmän poikkeamia kuin trainissa, ja notebook-analyysissä poikkeamien ominaisuudet eroavat train vs test. Tämä voi johtua mm. pienestä otoksesta, ajokertojen välisestä vaihtelusta, mittausasetelman muutoksista tai todellisesta driftistä.

6. Tuotantokäyttö (inference)

6.1 Tallennettavat komponentit

6.2 Käyttö tuotannossa

def detect_anomalies(new_data):
    # Lataa mallit
    model = joblib.load('anomaly_model.pkl')
    scaler = joblib.load('feature_scaler.pkl')
    feature_order = json.load(open('feature_order.json', 'r'))
    
    # Valmistele data
    X = new_data[feature_order].values
    X_scaled = scaler.transform(X)
    
    # Tee ennuste
    predictions = model.predict(X_scaled)
    scores = model.decision_function(X_scaled)
    
    return predictions, scores

6.3 Kynnysarvot ja hälytyssäännöt

Tässä toteutuksessa contamination=0.05 ohjaa mallin sisäistä päätösrajaa siten, että train-datassa noin 5% pisteistä merkitään poikkeamiksi. Dokumentointigraafeissa visualisoidaan lisäksi train-scoren 5% kvantiili (np.percentile(train_scores, 5)) suuntaa-antavana kynnysviivana.

Tuotantohälytyksessä suositellaan käyttämään ajallista aggregointia (esim. N viimeisen mittauspisteen poikkeamaprosentti) yksittäisten pisteiden sijaan, jotta virheelliset hälytykset vähenevät.

Tärkeää tuotannossa

  • Käytä aina samaa feature-järjestystä
  • Skaalaa data tallennetulla skaalainerilla
  • Tallenna tulokset ja seuraa suorituskykyä
  • Älä fit-taa skaalaineria tuotantodataan (muuten score-jakauma muuttuu ja driftin havainnointi vaikeutuu)

7. Monitorointi ja drift

7.1 Mitä monitoroidaan

7.2 Driftin merkit

Suositus

Kerää tuotannosta score- ja feature-telemetriaa vähintään aggregaattitasolla (esim. kvantiilit per ajokerta) ja vertaa niitä koulutusdatan baselineen. Tämä tukee sekä driftin havaintoa että hälytyskynnyksen säätöä.

8. Vianhaku

8.1 Yleiset ongelmat

Ongelma: KeyError puuttuvalle featurelle

Syy: Uusi data ei sisällä kaikkia tarvittavia featureja.

Ratkaisu: Varmista että kaikki featuret on laskettu samalla tavalla kuin koulutusdatassa.

Ongelma: Liian monta poikkeamaa

Syy: Contamination-parametri on liian suuri tai data on erilaista.

Ratkaisu: Säädä contamination-arvoa tai kerää lisää koulutusdataa.

Ongelma: Poikkeamat tulevat vain tietyissä ajokerroissa

Syy: Ajokertakohtainen vaihtelu (asennus, kuorma, sensorin offset) tai drift.

Ratkaisu: Vertaile feature-jakaumia train-baselineen ja harkitse ajokertakohtaista normalisointia tai uuden datan lisäämistä koulutukseen.

Ongelma: Malli ei lataudu

Syy: Mallitiedosto on korruptoitunut tai versio-ongelma.

Ratkaisu: Tarkista tiedostojen eheys ja scikit-learn versio.

8.2 Suorituskyvyn optimointi

Debug-vinkit

  • Tulosta aina featurejen nimet ja muodot
  • Käytä loggingia tuotannossa
  • Tallenna näytedataa ongelmien diagnosointiin

9. Ylläpito ja uudelleenkoulutus

9.1 Mallin uudelleenkoulutus

Kouluta malli uudelleen kun:

9.2 Uudelleenkoulutuksen minimivaatimukset (best practices)

9.3 Versionhallinta

9.4 Seuranta

Seuraa seuraavia metriikoita: