Moderní auta mají pod volantem diagnostický port. Zapojíte levný adaptér a můžete si přečíst část toho, co auto ví samo o sobě: chybové kódy, hodnoty senzorů, někdy i stav jednotlivých modulů.
Tahle data nejsou vždycky kompletní a rozhodně se neinterpretují snadno. Podstatné ale je něco jiného: ten stroj už mluví.
Přečíst ta data umí spousta nástrojů. Srozumitelně je vysvětlit? To je jiná liga.
Zamyslete se nad tím, co vlastně dělá automechanik. Připojí diagnostiku, vyskočí mu kód B1310 a pak několik minut porovnává tenhle kód se svými zkušenostmi, servisní příručkou pro konkrétní model a ročník, s tím, co mu řekl majitel, a s dalšími kódy z ostatních modulů. Samotný kód je jen ukazatel. Ta dovednost je v porovnávání. A buduje se roky.
Přitom auta v tomhle nejsou nic zvláštního. Klimatizace chrlí chybové kódy. Průmyslové PLC logují chyby do standardních protokolů. Lodní motory, řídicí systémy budov, skladová technika, výrobní linky. Všechno generuje strukturovaná diagnostická data. A ta data tam prostě leží a čekají, až je někdo s dostatečným výcvikem přečte a pochopí.
Problém není dostat se k datům. Problém je pochopit, co znamenají.
Vím to, protože se mi rozbila skládací střecha a několik týdnů jsem nechápal proč.
Rozbitá střecha
Mám Ford Focus CC z roku 2010, hardtop kabriolet. Střecha se složí do kufru za třicet sekund. Respektive skládala se, než odešel stahovač okna na straně spolujezdce. Uvnitř dveří se rozbil lankový mechanismus, motorek se točí, sklo se nehýbe a střecha odmítá fungovat.
Matoucí na tom bylo tohle: když jsem naskenoval palubní počítače, modul střechy hlásil nula chyb. Nic. Čisto. Mechanik zafixoval okno v poloze, střecha fungovala přesně jednou, pak zase přestala. A pořád žádné chybové kódy.
Nejsem automechanik, jsem programátor. Ale měl jsem tušení. Co když ten modul střechy vůbec není rozbitý? Co když dělá přesně to, k čemu byl navržený, a problém je úplně jinde?
Tak jsem udělal to, co mi jako vývojáři dávalo smysl: zpřístupnil jsem diagnostická data AI přes malý nástroj a nechal ji, ať mi vysvětlí, co vidí.
Když se dílky složí dohromady
Napsal jsem kousek softwaru, který umožní Claudovi (AI od Anthropicu) přistupovat k diagnostickým datům přes MCP, protokol pro zpřístupnění nástrojů AI systémům. Technické detaily najdete v popisu celé stavby. Tady ale nejde o kód. Jde o to, co se stalo, když měla AI všechny dílky před sebou.
Zpřístupnil jsem Claudovi to samé, co jsem předtím viděl ve FORScanu (oblíbená diagnostika pro auta): sken modulů plus lokální databázi chybových kódů sestavenou z veřejně dostupných zdrojů. Modul střechy čistý, nula chyb, jako vždycky. Jenže modul dveří spolujezdce měl dva kódy: selhání obvodu elektrického zámku a problém s obvodem vyhřívaného zrcátka.
A pak jsem se zeptal na to, co mě trápilo celé týdny: „Střecha nefunguje, ale modul střechy nemá žádné chyby. Proč?"
Odpověď nebyla skrytá. Byla rozházená po různých místech. Kousek ve skenu modulů, kousek v popisech chybových kódů, kousek v tom, jak vůbec funguje skládání střechy. Claude tyhle kousky vzal a složil z nich jedno vysvětlení.
Claude vysvětlil, že řadič střechy před zahájením skládací sekvence pošle příkaz modulům dveří: „mírně stáhni okno." Je to bezpečnostní kontrola. Střecha si musí ověřit, že okna jsou volná, než se přes ně přeloží. Pokud se okno nepohne, sekvence se přeruší. Ale žádná chyba se neuloží, protože z pohledu střechy se nic nepokazilo. Požádala okno o pohyb, okno se nepohnulo, tak přestala. Tohle není závada. Takhle to má fungovat.
Skutečný problém? Modul dveří. Stahovač okna je rozbitý, takže příkaz „stáhni okno" pokaždé selže. Střecha to pokaždé vzdá. Jenže chybové kódy, které vysvětlují proč, leží na úplně jiném počítači, v úplně jiné části auta.
Takhle mi to žádný mechanik nevysvětlil. Claude přišel se stejnou hypotézou prakticky okamžitě: nefunguje předřazený systém, na kterém střecha závisí, ne střecha samotná. Výměnou stahovače jsem to zatím neověřil, ale odpovídá to tomu, co jsem pak našel v servisní dokumentaci Fordu.
Proč tohle není jen o mém autě
Tady jsem se zastavil a začal přemýšlet. Nic magického se totiž nestalo. AI přečetla pár strukturovaných dat zpřístupněných přes úzkou sadu nástrojů. Vyhledala kódy v databázi. Propojila to se znalostmi o tom, jak fungují skládací střechy. Každý kousek těch informací už někde existoval: v paměti auta, v databázích kódů, v technické dokumentaci. Jenže existovaly v oddělených šuplících. Auto netuší, co jeho vlastní kódy znamenají normální řečí. Databáze kódů netuší, jak Ford řeší sekvenci střechy. Dokumentace netuší, co je konkrétně špatně s mým autem.
Mechanik vždycky dělal právě tohle: byl tím lidským tmelem mezi všemi těmihle zdroji. Přečíst kódy, mrknout do příručky, porovnat se zkušenostmi, vysvětlit zákazníkovi.
Tenhle malý prototyp s levným Bluetooth donglem dal AI schopnost dělat totéž, aspoň pro první odhad. A překvapivě jí to jde dobře. Ne že by byla chytřejší než mechanik. Jde o to, že vzít strukturovaná data, porovnat je se širokou znalostní bází a sestavit z toho srozumitelné vysvětlení je přesně to, co jazykové modely dělají.
Teď si představte každé další odvětví, kde existuje stejný vzorec.
Technik klimatizací zírá na chybové kódy ze střešní jednotky a porovnává je se servisní historií, konfigurací budovy a vlastními zkušenostmi. Lodní inženýr čte diagnostiku motoru na nákladní lodi a rozhoduje, jestli je bezpečné pokračovat v plavbě. Elektrikář řeší problém na PLC ve výrobě a porovnává chybové logy se schématy zapojení a manuálem stroje.
Hodně těchto scénářů vypadá stejně: ze standardního protokolu vypadnou strukturovaná data, vyškolený člověk je interpretuje pomocí oborových znalostí a výsledek je vysvětlení nebo rozhodnutí v normální řeči. Protokolová část přitom často není tak záhadná, jak vypadá. Auta mají OBD-II. Budovy mají BACnet. Průmyslové systémy často nabízejí Modbus, OPC UA nebo vendor API. Tyhle rozhraní nejsou vždycky čistá, úplná ani bezpečná k automatizaci, ale existují.
Naučit se ta data interpretovat trvalo vždycky roky. Jenže pro prvotní vysvětlení, triáž nebo shrnutí pro obsluhu se právě stalo mnohem snazší tohle doplnit.
Co tohle nenahrazuje
Jedna věc je důležitá: AI mi auto neopravila. Stahovač okna je pořád rozbitý, střecha se pořád neskládá. Pořád musím sundat dveřní panel, vyndat starý lankový mechanismus, dát tam nový a všechno zkalibrovat. Žádná AI to za mě neudělá.
A tohle je vlastně ten klíčový rozdíl. V každé opravě nebo diagnostice jsou dvě oddělené dovednosti. Pochopit, co je špatně. A fyzicky to opravit. AI umí pomoct s tím prvním, hlavně s rozpoznáváním vzorců a porovnáváním dat. Přečte data, propojí je se znalostmi a vysvětlí, co se děje, slovy, kterým rozumí každý. Ale ta druhá dovednost, ta praktická, pořád patří lidem. Nejspíš ještě hodně dlouho.
Nejde o nahrazení experta. Jde o to, aby to, co ví expert, pochopil i člověk bez výcviku. Dneska, když vám rozsvítí kontrolku motoru, máte dvě možnosti: zaplatit mechanikovi za diagnostiku, nebo vygooglit chybový kód a doufat, že někdo na fóru řešil totéž se stejným autem. Za první zaplatíte penězi a časem. Druhá je loterie. Mezi tím zeje obrovská mezera, kde byste mohli pochopit, co se s vaším strojem děje, kdyby vám to prostě někdo vysvětlil.
Tuhle mezeru AI zaplňuje. Ne opravu. Vysvětlení.
Větší vzorec
Že to funguje, mě ani tak nepřekvapilo. Překvapilo mě, jak málo kódu na to stačí. Prototyp mostu mezi diagnostickými daty a Claudem má zhruba 250 řádků. Protokol už byl standardizovaný. Diagnostický port tam už byl. Model už měl obecné znalosti o automobilových systémech. Stačilo propojit pár věcí.
Pořád se k tomu vracím. Fyzický svět je plný strojů, které už mluví. Mluví chybovými kódy, registry, event logy, hodnotami senzorů, zprávami specifickými pro daný protokol.
Nejde o to, aby AI ty stroje „řídila." Ve většině případů by neměla. Jde o to vybudovat nad daty, která ty stroje už produkují, bezpečnou vysvětlovací vrstvu. Rozhodnout, která data zpřístupnit, jaké akce zakázat, jak zajistit auditovatelnost a jak bezpečně propojit živý stav s oborovými znalostmi.
Diagnostický nástroj jsem dal na GitHub, protože tahle myšlenka je větší než jeden rozbitý kabriolet. Jestli děláte klimatizace, lodní inženýrství, průmyslovou automatizaci nebo řízení budov, sedíte na stejné příležitosti. Vaše stroje už mluví. Dokumentace může být ošklivá, neúplná nebo specifická pro jednoho výrobce, ale signály tam jsou. Chybí most: úzké nástroje, read-only přístup, kde to jde, oborový kontext a model, který dokáže převést stav stroje do lidské řeči.
Postavit ten most už není ta nemožná část. Těžké je postavit ho zodpovědně: rozhodnout, co zpřístupnit, co zakázat, jak zajistit auditovatelnost a kde musí zůstat rozhodnutí na člověku. Ale ta vysvětlovací vrstva, ta část, která převádí stav stroje na něco, o čem člověk dokáže přemýšlet, se najednou staví mnohem snadněji.
Tohle je typ rozhraní, které bude potřebovat čím dál víc firem: ne další dashboard, ale bezpečná překladová vrstva mezi provozními systémy a lidmi, kteří na nich závisí.
Stroje už mluví. Konečně máme lepší způsob, jak poslouchat.
*Technický popis stavby včetně kódu a návodu k nastavení: github.com/petrpatek/obd2-mcp-server*
