Не лише чат-боти: як LLM вбудовуються в інженерний workflow (CAD, електрика, АСУ ТП, проєкти, hardware)

Розширена версія вихідної статті «Не лише чат-боти: LLM у робочому процесі інженера-механіка» (2 грудня 2025). Мета: фокус на практичній автоматизації, а не «магічному проєктуванні» — насамперед там, де інженери втрачають час на повторюваних кроках, пошуку по документації, конвертації форматів і типових розрахунках.

:::tip Ключова ідея Використовуйте LLM як швидкий інтерфейсний шар для інженерних систем. Підсумкові результати тримайте детермінованими та валідуйте тестами, правилами й простежуваними джерелами. :::

1) Короткий розбір вихідної статті: що сильно, а що варто розширити

Сильні ідеї (збережені та посилені):

• LLM як інтерфейс до інструментів, а не «генератор деталей».
• Zero-shot генерація макросів і скриптів для скорочення часу освоєння API.
• Вилучення даних із PDF і таблиць у формати, готові для JSON/ERP/PDM.
• RAG за стандартами для точного пошуку у великих документах.
• Дисципліна структури промпта (контекст -> завдання -> обмеження).

Чого часто бракує (додано в цій розширеній версії):

• Валідація та відповідальність: вивід LLM зобов'язаний проходити тести й критерії приймання.
• Стратегія системної інтеграції: як LLM вписується в IDE, Git, CI, PDM/PLM, SCADA, ERP.
• Приклади для різних ролей: електрика, КВПіА/АСУ ТП, проєктна інженерія, hardware/PCB, якість, експлуатація.
• Непряме застосування з високим ROI: LLM пише утиліти, парсери, перевірки та невеликі повсякденні вебзастосунки.
• Workflow якості даних: parse -> normalize -> validate -> load, включно з обробкою шуму OCR.
• Безпека та конфіденційність: запобігання витокам креслень, BOM і комерційних даних.

2) Основна ідея: LLM — інженерний «клей» між системами

Ставтеся до LLM як до:

• помічника з мови та структури (описав задачу -> отримав код/шаблон/план),
• генератора чернеток (скрипт, макрос, SQL, Python, ST/IEC 61131-3, C#, PowerShell),
• нормалізатора даних (таблиці, PDF, BOM, специфікації),
• компаньйона зі стандартів (RAG, вилучення вимог, матриці простежуваності).

Не ставтеся до LLM як до:

• заміни інженерного судження,
• джерела істини за стандартами без верифікації,
• рушія для автономних критично важливих рішень.

Де LLM об'єктивно сильні

• Перетворення текстових інструкцій у структурований вивід.
• Переклад вимог в алгоритми та каркаси скриптів.
• Робота з патернами API/SDK (обхід дерева, фільтрація, пакетний експорт/імпорт).
• Генерація документації, чек-листів, тест-кейсів та обробки помилок.

Де вони слабші (і як це компенсувати)

• Просторове та геометричне мислення.
• Високоточна математика «на довірі».
• Впевнені галюцинації з невірними деталями.

Патерн компенсації: суворий ввід/вивід, тести, еталонні приклади, детерміноване виконання та приймальні перевірки.

3) Універсальний патерн впровадження: LLM + детермінований інструмент + валідація

Найкращі результати в інженерії зазвичай дає такий стек:

Engineer task -> prompt -> LLM (code/template/plan)
                         |
                         v
              deterministic executor
   (CAD API / Python / solver / simulator / parser / CI)
                         |
                         v
      validation (unit tests, rules, baseline comparisons)
                         |
                         v
          result (file, report, export, DB write)

Ключовий момент: LLM не «видає» фінальний інженерний результат напряму. Вона генерує інструкції та код. Фінальний результат — підсумок детермінованого виконання плюс верифікація.

4) Приклади за ролями: де реально швидкий ефект

Це сценарії з високою ймовірністю успіху: вони повторювані, насичені текстом і таблицями, дружні до API та тестовані.

4.1 Машинобудування / CAD / конструкторські бюро

Задачі, які добре автоматизуються:

• Пакетний експорт (DXF/DWG/PDF/STEP), потоки друку, генерація листів.
• Оновлення властивостей (матеріал, маса, позначення, ревізія), іменування файлів.
• Перевірки моделей (порожні властивості, невірні одиниці, нестандартні імена конфігурацій).
• Генерація звітів (BOM, зведення за масою, переліки змін).
• Пре/постобробка для розрахункових workflow (CSV у графіки та звіти).

Непрямо, але дуже ефективно:

• повсякденні утиліти для посадок, підбору різьби, перерахунку одиниць, перевірки правил іменування.

Приклад: валідатор позначень деталей (Python)

import re

RULE = re.compile(r"^[A-Z]{2}-\d{4}-[A-Z]{2}\d{2}$")  # Приклад: AB-1024-XY05

def validate_part_number(pn: str) -> bool:
    return bool(RULE.match(pn))

candidates = ["AB-1024-XY05", "ab-1024-XY05", "AB-102-XY05"]
for pn in candidates:
    print(pn, "OK" if validate_part_number(pn) else "FAIL")

Користь LLM: швидка генерація логіки валідації, CLI-інструментів, міні-застосунків на PyQt і каркасів плагінів, при цьому інженер контролює правила та приклади.

4.2 Інженери-електрики (схеми, щити, кабельні журнали, розрахунки)

Сильні сценарії:

• Генерація та перевірка кабельних журналів, переліків сигналів, I/O-списків.
• Автоматизація ланцюжків даних: навантаження -> групи -> автомати -> кабелі.
• Чернетки технічних вимог, пояснювальних записок, переліків обладнання.
• Нормалізація проєктних даних: чистка імен, приведення одиниць, пошук дублікатів.

Приклад: каркас швидкої утиліти розрахунку падіння напруги

from dataclasses import dataclass

@dataclass
class Line:
    length_m: float
    current_a: float
    voltage_v: float
    r_ohm_per_km: float  # Опір провідника за заданої температури

def voltage_drop_percent(line: Line) -> float:
    # Спрощена однофазна модель: dU = I * R
    # R = r_ohm_per_km * (L / 1000)
    r_total = line.r_ohm_per_km * (line.length_m / 1000.0)
    du = line.current_a * r_total
    return du / line.voltage_v * 100.0

l = Line(length_m=80, current_a=32, voltage_v=230, r_ohm_per_km=1.15)
print(f"Voltage drop: {voltage_drop_percent(l):.2f}%")

LLM можна попросити додати:

• імпорт таблиці кабелів із CSV/Excel і обмеження вибору,
• CLI + експорт звіту в PDF,
• unit-тести за еталонними випадками,
• пакування в командну утиліту.

Важливо: формули та поправочні коефіцієнти мають перевірятися за застосовними для вас стандартами (IEC/NEC/внутрішні правила). LLM прискорює реалізацію, а не узгодження відповідності.

4.3 Інженери АСУ ТП / КВПіА (PLC, SCADA, DCS)

Автоматизація з високим ефектом:

• Каркаси коду PLC (IEC 61131-3: ST/FBD) з функціональних описів.
• Нормалізація імен тегів і пошук дублікатів.
• Генерація текстів аварійних повідомлень і структур пріоритизації.
• Конвертація legacy: PDF-даташит -> структурований набір параметрів -> імпорт в інженерний інструмент.
• Перевірки узгодженості між I/O-списком, контурними схемами, тегами SCADA і переліками аварій.

Приклад: каркас функціонального блоку пуску двигуна на Structured Text

FUNCTION_BLOCK FB_MotorStart
VAR_INPUT
    StartCmd    : BOOL;
    StopCmd     : BOOL;
    EStopOk     : BOOL;
    InterlockOk : BOOL;
    FeedbackOn  : BOOL;
END_VAR
VAR_OUTPUT
    RunOut      : BOOL;
    Fault       : BOOL;
END_VAR
VAR
    latchedRun  : BOOL;
    tFeedback   : TON;
END_VAR

// Фіксація команди пуску
IF StopCmd OR NOT EStopOk THEN
    latchedRun := FALSE;
ELSIF StartCmd AND InterlockOk THEN
    latchedRun := TRUE;
END_IF;

RunOut := latchedRun AND EStopOk AND InterlockOk;

// Контроль зворотного зв'язку (спрощено)
tFeedback(IN := RunOut AND NOT FeedbackOn, PT := T#3S);
IF tFeedback.Q THEN
    Fault := TRUE;
    latchedRun := FALSE;
END_IF;

LLM допомагає згенерувати початковий каркас, діагностику, обробку станів, таймери, документацію та чернетки тест-кейсів для симуляції.

Відповідальність інженера залишається непорушною: логіка безпеки, умови зупинки, поведінка fail-safe, сценарії відмови датчиків і стандарти майданчика.

4.4 Проєктні інженери та міждисциплінарні команди (вимоги та координація)

Зони негайної користі:

• Перетворення розрізнених вимог у структуровані специфікації.
• Автогенерація матриць простежуваності вимог.
• Чернетки пакетів RFI/RFQ і шаблонів відповідей зацікавленим сторонам.
• Вилучення ризиків і доручень із протоколів зустрічей (з контролем конфіденційності).

Приклад потоку: вилучення вимог у JSON

Ідея промпта: «Перетвори цей вихідний текст у JSON зі схемою id, requirement, rationale, verification_method, priority.»

Далі:

• валідація за JSON Schema,
• імпорт у Jira/Polarion/DOORS/Confluence,
• генерація планів верифікації.

4.5 Інженери hardware і PCB (BOM, автоматизація тестів, каркаси прошивок)

Цілі з високою віддачею:

• Нормалізація BOM: виробник, MPN, аналоги, одиниці, описи.
• Генерація скриптів стендових випробувань (Python + SCPI/PyVISA, serial, CAN).
• Каркаси прошивок (драйвери, скінченні автомати, обробники протоколів) із суворим ревʼю.
• Чек-листи bring-up і чернетки планів виробничих тестів.

Приклад: мінімальна обгортка ідентифікації за SCPI

import pyvisa

def read_idn(resource: str) -> str:
    rm = pyvisa.ResourceManager()
    inst = rm.open_resource(resource)
    inst.timeout = 5000
    return inst.query("*IDN?").strip()

print(read_idn("USB0::0x0000::0x0000::INSTR"))

LLM швидко додасть повторні спроби, діагностику з'єднання, структуровані логи, експорт CSV/JSON, зручний CLI і зведення прогонів тестів.

5) Детальні кейси з рецептами впровадження

Кейс A: zero-shot CAD-скрипти з контролем якості

Задача: пакетний експорт усіх листових деталей зі складання в DXF, з папками та логами.

Чому LLM допомагає швидко:

• обхід складання,
• фільтрація листових деталей,
• параметри експорту,
• правила іменування,
• обробка помилок і логування.

Безпечна послідовність впровадження:

1. Визначте явні входи та виходи.
2. Згенеруйте каркас на CAD API (VBA/C#/Python).
3. Додайте приймальні перевірки:
   • очікувана кількість файлів,
   • відповідність шаблону іменування,
   • відхилення дублікатів/порожніх імен,
   • повний статусний лог.
4. Спочатку прогін на тестовому складанні, потім на робочому.
5. Ведіть версіонування в Git із фіксованими версіями CAD/плагінів.

Шаблон промпта для генерації CAD-скрипта

Context:
- CAD: SolidWorks 2023
- Language: VBA (or C#)
- Object: active assembly (.sldasm)

Task:
- Find all sheet-metal parts, including nested subassemblies
- Export each to ./ExportDXF/<PartNumber>/
- File naming: <PartNumber>_<ConfigName>.dxf

Constraints:
- Skip suppressed components
- Never overwrite files (append suffix instead)
- Write log.csv with part, config, status, message

Acceptance criteria:
- For a 10-part sheet-metal test assembly, produce 10+ DXFs (depending on configs)
- Log must have no empty fields and include error codes

Кейс B: PDF -> JSON -> PDM/ERP для даташитів

Задача: вилучити параметри з даташитів (наприклад, датчиків тиску) і створити структуровані записи.

Типова складність: PDF бувають як текстовими, так і сканованими зображеннями.

Рекомендований pipeline:

1. Текстовий PDF: парсинг таблиць Python-інструментами (pdfplumber, camelot, tabula) і нормалізація.
2. Сканований PDF: захоплення ключових сторінок і мультимодальне вилучення в JSON.
3. Валідація всього:
   • відповідність схемі,
   • узгодженість одиниць,
   • простежуваність джерела (файл, сторінка, рядок таблиці).

Приклад мінімальної JSON-схеми

{
  "tag": "PT-101",
  "device_type": "Pressure Transmitter",
  "manufacturer": "ACME",
  "model": "X200",
  "range": {"min": 0, "max": 10, "unit": "bar"},
  "output": "4-20 mA + HART",
  "supply": {"min": 12, "max": 30, "unit": "VDC"},
  "process_connection": "G1/2",
  "materials": {"wetted": "316L"},
  "ip_rating": "IP67",
  "source": {"file": "datasheet_x200.pdf", "page": 3}
}

Ключова тактика: вимагайте від моделі строго JSON-only вивід.

Шаблон промпта для вилучення таблиць

You are given a table image (page 3). Return JSON only with this schema:
- manufacturer (string)
- model (string)
- range.min (number), range.max (number), range.unit (string)
- supply.min (number), supply.max (number), supply.unit (string)
- output (string)
- ip_rating (string)
Use null when a value is missing.

Кейс C: RAG за стандартами та внутрішніми регламентами

Задача: відповідати на питання на кшталт моментів затягування, допусків і правил маркування з посиланнями на джерела.

Потік RAG:

• індексація PDF і внутрішніх документів,
• вилучення релевантних фрагментів,
• відповідь на основі знайденого,
• збереження посилань на документ/сторінку.

PDF/docs -> chunking -> embeddings -> vector DB
                              |
                              v
                         user query
                              |
                              v
                   top-k retrieved fragments
                              |
                              v
                  LLM answer + source citations

Практичне правило: зберігайте версію стандарту, дату набуття чинності та внутрішні винятки поруч із кожним індексованим джерелом.

Кейс D: LLM як генератор мікрозастосунків для повсякденних інженерних задач

Іноді найвищий ROI дає невеликий сервіс, а не повноцінний «агент».

Приклади:

• вебформа для вхідних параметрів -> валідований звіт,
• бот для Slack/Teams з чек-листами та посиланнями на стандарти,
• надбудова Excel для потоків нормалізації даних.

Приклад каркаса на FastAPI

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Input(BaseModel):
    length_m: float
    current_a: float
    voltage_v: float
    r_ohm_per_km: float

@app.post("/voltage-drop")
def voltage_drop(inp: Input):
    r_total = inp.r_ohm_per_km * (inp.length_m / 1000.0)
    du = inp.current_a * r_total
    return {"drop_percent": du / inp.voltage_v * 100.0}

LLM швидко додасть OpenAPI-документацію, валідацію, логи, Dockerfile і покриття тестами.

6) Практика промптингу для інженерів: шаблони, які справді працюють

6.1 Універсальний промпт для інженерного коду

1) Context
- Tool/version: (SolidWorks 2023 / EPLAN / TIA Portal / KiCad / Python 3.11)
- Language: (VBA/C#/Python/ST)
- Environment constraints: (offline, stdlib-only, access limits)

2) Inputs
- What comes in? (file, folder, CSV, parameters)
- At least one sample input

3) Outputs
- What should be produced? (files, report, JSON, model changes)
- Strict output format

4) Rules
- Naming, units, standards, exceptions
- Error definitions

5) Acceptance criteria
- 3-5 verifiable checks
- Preferably test cases (input -> expected output)

6.2 Завжди просіть тести

Доповнення до промпта, що підвищують надійність:

• «Згенеруй 5 unit-тестів pytest для граничних випадків формули.»
• «Додай конфігурацію статичної типізації (mypy) і лінтингу (ruff).»

Це помітно знижує кількість «тихих» логічних помилок.

7) Контроль якості: як уникнути хаосу через LLM

Мінімальний набір практик, що працює в продакшені:

• Використовуйте Git для всіх скриптів/макросів.
• Вимагайте code review людиною.
• Ведіть логи та звіти про виконання.
• Підтримуйте еталонні набори даних (тестові складання, тестові PDF, тестові теги).
• Застосовуйте JSON Schema і строгі формати виводу.
• Блокуйте автоматичний запис без попереднього dry-run + звіту.

Практичне правило: LLM прискорює створення артефактів (код, документація, таблиці), але відповідальність за інженерні рішення залишається за кваліфікованими інженерами та перевіреними детермінованими інструментами.

8) Реалістичний план впровадження на 2-4 тижні

Тиждень 1: виберіть 1-2 больові точки

• Приклади: експорт DXF, чистка BOM, генерація I/O-списків, розрахунок падіння напруги.

Тиждень 2: прототип

• Скрипт + один тестовий набір даних + лог виконання.
• Внутрішній README з інструкцією із запуску.

Тиждень 3: обв'язка якості

• Unit-тести, валідація форматів, обробка помилок.
• Git-репозиторій і дисципліна версій.

Тиждень 4: пілот у роботі

• Інструктаж команди.
• Пілот на реальних даних.
• Цикл зворотного зв'язку та ітерації.

9) Головний висновок

LLM — це не про «нехай ШІ спроєктує за мене». Це про:

• автоматизацію рутини (експорт, властивості, звіти, таблиці),
• пришвидшену розробку внутрішніх інструментів (скрипти, калькулятори, валідатори),
• структуроване вилучення знань (PDF -> JSON, RAG за стандартами),
• зростання якості за рахунок прозорих pipeline і тестів.

Роль інженера зміщується від оператора інтерфейсів до архітектора автоматизації: визначати правила, перевіряти результати та будувати відтворювані workflow.

Навігація за тегами до інших опублікованих статей

Використовуйте теги для переходу між пов'язаними матеріалами:

• #automation
• #cad
• #llm
• #ai
• #python

Опубліковані статті, пов'язані цими тегами:

• Headless CAD: генерація та розкрій DXF-розгорток через Chromium
• Не лише чат-боти: LLM у робочому процесі інженера-механіка
• Excalidraw: віртуальна серветка для інженера
• FreeCAD 1.x: «король» open-source CAD