Zpět na portfolio
Case Study

Monitoring teplot

Monitoring teplot v chladicích boxech stovek vozů

Schéma architektury systému pro monitoring teplot: datové zdroje, normalizace, .NET API, MS-SQL a mobilní klient přes DMZ

O projektu

Klient rozváží léčiva ve stovkách vozů, každý s chladicím boxem osazeným teplotními čidly. Odchylka teploty znamená znehodnocenou zásilku a problém při auditu, takže bylo potřeba vidět stav celého vozového parku okamžitě, ne až ze záznamů. Systém sbírá data z několika nezávislých zdrojů, každý s vlastním formátem, sjednocuje je do jednoho datového modelu a zobrazuje v dashboardu, který se aktualizuje průběžně bez obnovování stránky. Součástí je mobilní aplikace v .NET MAUI, díky které mají řidiči i dispečink přehled mimo kancelář. Backend běží v interní síti, komunikace s mobilními zařízeními prochází přes bránu v DMZ. Klient je vázán NDA, takže tato studie neobsahuje snímky obrazovky ani identifikační údaje. Přiložené schéma zachycuje architekturu řešení. Vývoj probíhal agilně, v krátkých iteracích s pravidelnými demy a průběžným nasazováním, takže klient viděl funkční části systému dlouho před dokončením celku.

Informace o projektu

Klient

Farmaceutická společnost (pod NDA)

Platforma

Multi-platforma

Stav

Dokončeno

Doba vývoje

7 měsíců

Rok

2026

Použité technologie

Podívejte se na stack, který jsem použil pro tento projekt

Frontend

.NET MAUI

Backend

.NETC#Entity FrameworkSignalRREST API

Databáze

MS-SQL

Cloud

DMZ / on-premise

Klíčové funkce

Realtime dashboard nad celým vozovým parkem

Teplotní čidla v chladicích boxech stovek vozů

Agregace dat z několika zdrojů s odlišnými formáty

Normalizace do jednotného datového modelu včetně validace

Řízení přístupů podle rolí a auditní stopa nad každou změnou

Alarmy při překročení mezních hodnot u konkrétního vozu

Mobilní aplikace v .NET MAUI pro řidiče a dispečink

Historie měření a exporty pro potřeby auditu

Výzvy

  • 1

    Stovky vozů hlásících měření současně a v různých intervalech

  • 2

    Každý datový zdroj používal jiný formát i jinou strukturu záznamů

  • 3

    Dashboard musel zobrazovat aktuální stav bez ručního obnovování

  • 4

    Backend v interní síti, ale mobilní klient ve vozech mimo ni

  • 5

    Zadání se v průběhu upřesňovalo podle zkušeností z reálného provozu

Řešení

  • 1

    Datový model a dotazy navržené na průběžný přísun měření z celého parku

  • 2

    Normalizační vrstva převádějící všechny vstupy na jednotný model

  • 3

    Průběžné doručování změn do dashboardu místo pravidelného dotazování

  • 4

    Brána v DMZ s autentizací zařízení jako jediný průchod ven

  • 5

    Agilní vývoj v krátkých iteracích: pravidelná dema, průběžné nasazování a úpravy priorit podle zpětné vazby

Výsledky

Stav všech vozů na jedné obrazovce místo několika oddělených systémů

Odchylka teploty viditelná okamžitě, ne až při kontrole záznamů

Doložitelná historie měření pro potřeby auditu

Přístup k datům z terénu bez zásahu do bezpečnosti interní sítě

Průběh vývoje

Od analýzy po nasazení - jak probíhal vývoj projektu

5 týdnů

Analýza a návrh

Mapování datových zdrojů, návrh datového modelu a bezpečnostní architektury, rozpad na iterace

6 týdnů

Integrační vrstva

Napojení zdrojů, normalizace formátů, validace a deduplikace dat po iteracích

9 týdnů

Backend a dashboard

API v .NET, databázový model, realtime aktualizace, role a auditní stopa s demem na konci každé iterace

5 týdnů

Mobilní aplikace

Klient v .NET MAUI a zabezpečená komunikace přes bránu v DMZ, testováno průběžně s uživateli

5 týdnů

Testování a nasazení

Ověření scénářů, zátěžové testy a nasazení do interní infrastruktury

Máte podobný projekt?

Rád vám pomohu s realizací vaší aplikace. Neváhejte mě kontaktovat pro nezávaznou konzultaci.

Kontaktovat