Ennen kuin dataa kerätään ja mallia koulutetaan, ongelma pitää määritellä tarkasti, eli mitä halutaan ennustaa tai tunnistaa. Ilman selkeää ongelmanmäärittelyä dataa voidaan kerätä vääristä lähteistä tai väärässä muodossa, jolloin malli oppii epäolennaisia asioita tai tulokset eivät ole hyödynnettävissä tuotannossa. Hyvä määrittely ohjaa myös mallityyppiä (esim. luokittelu, regressio, anomaliatunnistus).
Halutaan tunnistaa servon liikeradan poikkeamat. Käytännössä “poikkeama” tarkoittaa sitä, että servon liike tai siihen liittyvä värinä näyttää erilaiselta kuin normaalisti, esimerkiksi liike nykii, värinä kasvaa selvästi tai liikerata ei toistu samalla tavalla kuin aiemmin. Servon liikeradan poikkeamien tunnistamisessa tavoitteena on havaita tilanteet, joissa liike tai siihen liittyvä värinä poikkeaa normaalista. Tämä on luontevaa tehdä ML-mallilla, koska signaali vaihtelee luonnostaan olosuhteiden mukaan (esim. kuorma, kiinnitys, lämpötila, sensorin kohina), jolloin käsin koodatut kynnysarvot ja säännöt johtavat helposti joko liian herkkään hälyttelyyn tai poikkeamien ohittamiseen. Malli voi oppia kerätystä datasta normaalin käyttäytymisen piirteet ja erottaa aidot poikkeamat tyypillisestä vaihtelusta ilman, että jokainen poikkeustilanne täytyy ennakoida sääntölogiikassa.
Mittareilla määritellään, milloin ratkaisu toimii riittävän hyvin ja milloin siihen pitää reagoida. Käytännössä kannattaa sopia vähintään (1) mallin tuottaman hälytyksen hyödyllisyydestä (esim. hälytyksiä ei tule liikaa eikä liian vähän), (2) suorituskyvystä (viive, kapasiteetti), sekä (3) vakaudesta ajan yli (driftin merkit). Alussa, kun "oikeaa totuutta" poikkeamista ei aina ole saatavilla, voidaan käyttää myös käytännönläheisiä seurantamittareita kuten poikkeamien osuus per ajokerta, anomaly score -jakauman muutokset ja hälytysten määrä per aikajakso.
Käytännössä servon liikeradan seurannassa kannattaa katsoa esimerkiksi sitä, kuinka usein järjestelmä antaa hälytyksen, tuleeko hälytyksiä liikaa ja tuleeko hälytykset samoissa tilanteissa vai satunnaisesti. Lisäksi on hyvä seurata, kuinka nopeasti järjestelmä vastaa (tuleeko tulos heti vai viiveellä) ja tuleeko virheitä tai katkoksia. Jos mahdollista, kannattaa silloin tällöin tarkistaa muutama hälytys käsin, eli oliko se oikeasti poikkeama vai turha hälytys. Näin näkee nopeasti, onko ratkaisu hyödyllinen ja pysyykö se ajan mittaan järkevänä.
Data kerätään servoon kiinnitetystä 3-akselisesta kiihtyvyysanturista. Anturi mittaa liikkeen aikana kiihtyvyyttä X-, Y- ja Z-suunnissa ja näytteitä otetaan tasaisella aikavälillä, jotta koko liikerata saadaan talteen. Mittaus tehdään liikesyklin aikana, eli jokaiselle näytteelle tallennetaan aikaleima, servon kulma sekä kiihtyvyysarvot. Näin muodostuu mittausjakso, jota voidaan käyttää sekä poikkeamien tunnistamiseen että myöhempään analysointiin.
Alla on yhden näytteen rakenne. Mittausjakso koostuu useista peräkkäisistä näytteistä. Tyypillinen näytteenottotaajuus on noin 50 Hz (20 ms välein), jolloin esimerkiksi 2 sekunnin mittausjakso sisältää noin 100 näytettä.
{
"measurements": [
{
"time_ms": 0,
"angle": 0,
"acceleration": {
"x": 2032,
"y": 1991,
"z": 1638,
"total": 3282
}
}
]
}Mittausdata siirretään sarjaliikennettä pitkin Edge-laitteelle. Edge-laitteessa data vastaanotetaan siirtomoduulilla, joka lukee viestit sarjaportista, jolloin data voidaan reitittää Edge-laitteen sisäisen viestinvälityksen kautta pilveen ja lopulta se siirtyy IoT Hubille.
Embedded AI (TinyML) -ratkaisussa data lähetetään suoraan laitteesta IoT Hubille ilman erillistä Edge-laitteen välissä olevaa siirtomoduulia. Tällöin laite muodostaa yhteyden IoT Hubiin ja lähettää mittausdatan suoraan eteenpäin, jolloin siirtopolku on yksinkertaisempi.
Kerätty data tallennetaan tietokantaan, esimerkiksi PostgreSQL:ään, jotta mittausjaksot ovat helposti haettavissa, analysoitavissa ja käytettävissä mallin koulutukseen sekä myöhempään vertailuun. Dataa ja mallin artefakteja (esim. koulutusdata, esikäsittely ja malliversiot) kannattaa versioida Azure ML Workspacessa, jolloin voidaan jälkikäteen osoittaa, millä datalla ja millä asetuksilla tietty malli on rakennettu ja otettu käyttöön.