Gestire un progetto PLC senza controllo di versione significa accettare rischi evitabili: sovrascritture, scarsa tracciabilità, rollback lenti e difficoltà nel capire quale versione sia realmente in produzione. Git è una risposta efficace anche nell'automazione industriale, ma va chiarito un punto importante: TIA Portal non si comporta come un IDE software con un client Git completo integrato. Il flusso corretto passa attraverso la Version Control Interface (VCI), i workspace nel file system e, nelle versioni più recenti, i SIMATIC Source Documents (SIMATIC SD).

Correzione chiave: in TIA Portal V20/V21 Siemens documenta l'integrazione con sistemi di versionamento esterni come Git tramite Version Control Interface. La documentazione ufficiale specifica che TIA Portal non interagisce direttamente con il programma di version control: entrambi lavorano sugli stessi workspace nel file system. Manuale ufficiale VCI V21 →

Perché Git serve davvero nell'automazione

In un impianto industriale, il software PLC ha impatti operativi, manutentivi e di sicurezza comparabili a quelli del software IT. Usare Git non elimina da solo tutti i rischi, ma migliora in modo concreto quattro aspetti fondamentali:

  • Tracciabilità — sai chi ha cambiato cosa, quando e con quale motivazione
  • Rollback — puoi tornare rapidamente a una baseline nota
  • Collaborazione — il team lavora con branch, review e integrazione controllata
  • Auditabilità — change log, tag e policy di approvazione supportano il change management

Questo non significa che Git garantisca da solo la conformità normativa. Significa però che offre un'infrastruttura molto più solida rispetto a cartelle condivise, copie manuali o file nominati Progetto_finale_v7_definitivo_2.

Cosa supporta davvero Siemens

La documentazione Siemens descrive tre elementi chiave:

  1. Version Control Interface (VCI) — collega il progetto TIA a file esportati in uno o più workspace
  2. Tool esterni di versioning — Git, Subversion o altri strumenti che lavorano su quei file
  3. Formati esportabili testuali — XML, formati specifici di blocco e, nelle versioni più recenti, SIMATIC SD

Questa distinzione è importante perché evita un errore frequente: parlare di "Git nativo in TIA Portal" come se esistessero funzioni ufficiali documentate del tipo Initialize Git repository, Commit, Push e gestione del remote direttamente dentro l'IDE. Nelle fonti ufficiali Siemens verificate per questo articolo, quel flusso non è documentato.

Prerequisiti realistici

TIA PortalV20 o V21 consigliato per VCI matura e SIMATIC SD; versioni precedenti possibili ma più limitate
VersionamentoGit installato e aggiornato, con client CLI o grafico esterno
PiattaformaGitLab, GitHub, Gitea, Azure DevOps o server Git self-hosted
CompetenzeCommit, branch, merge, tag e gestione di base dei conflitti
Nota storica utile: la VCI non nasce in V21. Siemens documenta già in TIA Portal V16 il collegamento a strumenti di versioning esterni come Git e Subversion, con confronto blocchi via UI o tramite tool terzi. Novità V16: Engineering options →

1. Il modello corretto: progetto TIA, workspace e repository Git

Il modello più robusto non consiste nel versionare alla cieca l'intera cartella binaria del progetto TIA, ma nel versionare i file esportati dal progetto verso uno workspace. In pratica:

TIA Portal project
        ↓
Version Control Interface (VCI)
        ↓
Workspace sul file system
        ↓
Git (CLI o client grafico esterno)
        ↓
Repository locale/remoto

In questo schema TIA Portal gestisce l'associazione tra oggetti di progetto e file nel workspace, mentre Git tiene traccia delle modifiche ai file esportati.

2. Struttura del repository consigliata

Non esiste una struttura unica imposta da Siemens, ma questa organizzazione è pratica e coerente con un workflow industriale:

plant-project/
├── .gitignore
├── .gitattributes
├── README.md
├── workspace/
│   ├── plc/
│   ├── hmi/
│   ├── types/
│   └── libraries/
├── docs/
│   ├── commissioning/
│   ├── electrical/
│   ├── functional-specs/
│   └── changelog.md
├── scripts/
│   ├── export-vci.ps1
│   ├── backup-online.ps1
│   └── compare-workspace.ps1
└── test/
    └── plcsim/

La cartella workspace/ è quella più importante: contiene gli oggetti esportati e quindi confrontabili in Git.

.gitignore: cosa escludere

I file temporanei, cache e log non dovrebbero finire nel repository. Un esempio prudente:

# Temporanei e backup
*.tmp
*.bak
*.compiled

# Cache e log
**/Cache/
**/Logs/
**/UserFiles/
**/.Trash/
**/BackupCopies/

# Informazioni di compilazione rigenerabili
**/*.compileinfo

# Sistema operativo
Thumbs.db
desktop.ini
.DS_Store

Questo elenco va adattato al tuo progetto reale. La documentazione Siemens non pubblica un .gitignore standard ufficiale generato automaticamente da TIA Portal, quindi è meglio evitare di promettere un file "ottimizzato" creato dall'IDE.

⚡
Git LFS: può essere utile per file binari grandi, asset grafici HMI o allegati tecnici. Non è un requisito Siemens, ma è spesso una buona scelta pratica quando il repository cresce troppo.

3. Configurazione corretta in TIA Portal V20/V21

Il workflow corretto con TIA Portal V20/V21 è questo:

  1. Apri il progetto in TIA Portal
  2. Configura la Version Control Interface
  3. Crea uno o più workspace sul file system
  4. Definisci i formati di export per i tipi di oggetto supportati
  5. Collega gli oggetti del progetto ai file del workspace
  6. Sincronizza progetto e workspace
  7. Versiona il workspace con Git esterno

Per il confronto tra file, Siemens prevede anche la configurazione di un programma di comparison esterno. È una parte ufficiale della VCI, non un workaround improvvisato. Configurare un comparison program esterno →

4. Formati di export: non è solo "XML"

Un'altra semplificazione comune è dire che il versionamento di TIA Portal si basa semplicemente su "export XML". In realtà Siemens usa formati diversi a seconda dell'oggetto. Nella documentazione VCI, per esempio:

  • LAD / FBD / GRAPH — storicamente esportati come XML nella VCI classica
  • SCL e STL — possono usare XML oppure formati specifici di blocco, a seconda della configurazione
  • DB e UDT — possono avere formati specifici oltre all'XML
  • HMI Unified scripts — esportati in file testuali come JavaScript e YAML, secondo la VCI
  • V20/V21 — introducono ed estendono SIMATIC SD come formato testuale più leggibile e adatto al versionamento

Per questo motivo la frase "Project → Export → SimaticML e poi Git" è troppo riduttiva. SimaticML e Openness restano strumenti importanti, ma il quadro reale è più ampio. Panoramica ufficiale dei formati di export →

5. SIMATIC SD: la svolta pratica per il versionamento

Uno dei miglioramenti più interessanti introdotti da Siemens riguarda i SIMATIC Source Documents (SIMATIC SD), cioè file testuali pensati per essere letti, modificati e versionati più facilmente rispetto ai formati precedenti.

In V20 Siemens evidenzia il supporto SIMATIC SD per LAD, DB e PLC data types. In V21 il supporto viene esteso anche a FBD, SCL e blocchi misti. Questo è probabilmente il vero passo avanti che rende Git molto più praticabile in TIA Portal, più ancora di qualsiasi slogan sul "Git nativo". Novità STEP 7 in V21 →

I manuali Siemens indicano esplicitamente che i file esportati in SIMATIC SD possono essere usati indipendentemente da TIA Portal, modificati con un editor di testo e gestiti in un version control system. Guida ufficiale SIMATIC SD →

6. Quali oggetti si prestano davvero al versionamento

La VCI non copre indistintamente "tutto il progetto". Siemens documenta il versionamento di diversi oggetti, tra cui:

  • OB, FB, FC
  • Data block e PLC data types
  • PLC tag tables
  • Technology objects
  • Global scripts di HMI Unified
  • Project library types in V21

Esistono però limiti espliciti. Siemens segnala come non supportati o problematici, a seconda dei casi:

  • CEM blocks
  • Blocks with know-how protection
  • Fail-safe objects protetti da password quando non si conosce la password

Quindi è corretto dire che Git + VCI migliorano molto il controllo versione dei progetti PLC, ma non è corretto promettere una tracciabilità perfetta e universale di ogni singolo elemento. Limitazioni ufficiali della VCI →

7. Branching workflow consigliato

Per i progetti PLC funziona bene un modello semplice:

main              ← baseline rilasciata / produzione
  └── develop     ← integrazione modifiche
       ├── feature/nuovo-ciclo-lavaggio
       ├── feature/allarmi-sicurezza
       └── hotfix/fix-encoder-asse-3
  • main contiene solo versioni approvate e scaricate o pronte per il download
  • develop integra le modifiche verificate in ambiente di test o simulazione
  • feature/* isola ogni modifica funzionale significativa
  • hotfix/* gestisce urgenze partendo dalla baseline effettivamente in campo

Questo modello non è imposto da Siemens, ma è coerente con le esigenze di impianto: stabilità, rollback rapido e chiara separazione tra sviluppo e produzione.

8. Commit message: più importanti di quanto sembri

Un buon commit dovrebbe dire cosa è cambiato, dove e possibilmente perché.

Messaggi deboli

fix
aggiornamento
modifiche varie
test
Messaggi utili

Corretto timeout encoder asse 3 in FC30 e DB_Assi
Aggiunto ciclo CIP stazione lavaggio in FB40
Aggiornata diagnostica HMI Unified per allarme forno 2
Hotfix: corretto scaling PT100 linea essiccazione

9. Gestione dei conflitti: niente promesse irrealistiche

I conflitti non spariscono con Git; diventano più gestibili. In TIA Portal il punto corretto da comunicare è questo:

  • la VCI consente di confrontare oggetti di progetto e file del workspace
  • Siemens prevede la configurazione di tool esterni di comparison
  • i formati testuali come XML, SCL, DB, UDT e soprattutto SIMATIC SD rendono il diff molto più utile
  • i file binari restano più difficili da fondere e richiedono coordinamento del team

La tesi corretta non è "TIA fa merge Git come un IDE moderno", ma: TIA offre una base concreta per confronto e sincronizzazione, e Git gestisce il versionamento dei file esportati.

10. CI/CD: possibile, ma tramite Openness e strumenti esterni

Per i team più maturi, Siemens mette a disposizione TIA Portal Openness, che consente di automatizzare attività di engineering. La documentazione ufficiale copre, tra le altre cose:

  • apertura e gestione dei progetti
  • compilazione di dispositivi e blocchi
  • download di hardware e software verso PLC

Questo significa che scenari come export workspace → commit → pipeline CI → compile check → validazione → download controllato sono realistici, ma non perché TIA Portal includa un CI/CD integrato: sono possibili grazie a Git + pipeline esterne + Openness API. Compilazione via Openness → · Download a PLC via Openness →

11. Sicurezza e compliance: cosa si può dire senza esagerare

Git aiuta molto su audit trail, segregazione dei ruoli, review e controllo delle release. Questo supporta pratiche di change management utili in contesti regolati e industriali. Però sarebbe scorretto dire che IEC 62443 o NIS2 "richiedono Git" oppure che usare Git equivale di per sé alla conformità.

La formulazione più rigorosa è questa: Git è un ottimo abilitatore tecnico di processi di controllo modifica, revisione e tracciabilità, ma la conformità dipende anche da governance, procedure, gestione accessi, backup, incident management e sicurezza operativa.

12. Checklist di avvio davvero utile

1. Scegli la baselineIdentifica con certezza la versione attuale in produzione
2. Attiva VCIConfigura workspace, formati export e comparison tool
3. Seleziona i formati giustiUsa SIMATIC SD dove disponibile; altrimenti XML o formato specifico
4. Crea il repositoryVersiona il workspace e la documentazione tecnica
5. Definisci i branchmain, develop, feature/*, hotfix/*
6. Proteggi le releaseTag, review obbligatorie e policy di merge
7. Forma il teamCommit atomici, messaggi chiari, regole di sincronizzazione col PLC

Il nostro punto di vista

Git ha senso nei progetti PLC, ma funziona bene solo se viene adottato con il modello corretto. L'errore più comune è voler usare TIA Portal come se fosse un IDE software con Git integrato in ogni pannello. La realtà documentata da Siemens è più sobria ma anche più concreta: workspace versionati, export leggibili, comparison esterni e automazione via Openness.

È meno "magico" di come a volte viene raccontato, ma è comunque un salto di qualità enorme rispetto a copie manuali, backup sporadici e gestione non tracciata delle modifiche.

Vuoi introdurre un workflow Git serio nei tuoi progetti di automazione?

Parti da una baseline stabile, scegli i formati giusti e definisci regole semplici. La tecnologia conta, ma conta ancora di più il processo con cui il team la usa.

Risorse ufficiali e guide utili