PLC software documentation, flowcharts and state diagrams

Random thoughts…

Just found this basic yet interesting article on my rss feed: https://www.controldesign.com/articles/2019/how-to-document-a-plc-program/

It highlight the fact that in real life documenting a PLC software is still considered a simplified version of the “real software documentation” process, unfortunately.

But during reading the referred article https://www.controldesign.com/articles/2017/how-to-write-a-plc-step-sequence-program we should also remember that 61131-3 standard defines an SFC programming language dedicated to step sequence programming https://en.wikipedia.org/wiki/Sequential_function_chart.

Going one step further, i’ve been practicing recently with a very interesting system implementing a complete State Charts Diagram editor as part of a more complex embedded UML editor. Yes, when i mention State Charts I’m talking about this http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf

Finally…!!!

Qualche appunto sul backup dei dati

Si parlava con un amico di come “fare il backup del portatile” e ho notato come al giorno d’oggi ci sia ancora tanta confusione a riguardo.

Ho deciso cosi’ di dedicare il mio primo post in Italiano proprio a quest’argomento.

Non c’e’ ovviamente una soluzione universale al problema, ma la seguente e’ una strategia abbastanza comune per conciliare il bisogno di un archivio sicuro e privato con quello di mantenerlo aggiornato e facilmente ripristinabile:

  1. Mantenere una copia online su un server remoto, aggiornata con maggior frequenza possibile.
  2. Mantenere una copia offline facilmente raggiungibile e aggiornata quando ritenuto opportuno, ad esempio settimanalmente, mensilmente o ad una certa milestone.

Questo permette di:

  • Avere un live backup sul server remoto, usando ad esempio rsync con inotify o rsync con cron/anacron.
  • Poter eseguire un disaster recovery dei dati dalla copia offline.
  • Usare rsnapshot per permettere l’accesso a precedenti versioni dei file sia sul server remoto che sulla copia offline.

Rimane da valutare la sicurezza del sistema operativo in caso di attacchi esterni:

  • Il rischio di accesso ai dati da parte di personale non autorizzato non puo’ essere escluso, visto che parte del sistema rimane online.
    Puo’ essere pero’ notevolmente ridotto utilizzando gli strumenti corretti, ad esempio un sistema operativo open source ( i.e. GNU Linux) meglio se con installazione minimale e tenuta costantemente aggiornata, accesso tramite SSH, ecc…
  • La presenza della copia offline garantisce la possibilita’ di recupero dei dati in caso di attacchi distruttivi da parte di hackers.
  • Tutti i supporti dovrebbero ovviamente essere cifrati (i.e. LUKS).

Ci sono infine le varie soluzione “cloud” che in moltissimi casi offrono un’ottima alternativa per sostituire o integrare le tecniche introdotte in questo post.

What’s wrong with PLC editors, seriously?

If you don’t use Git you’re ugly and stupid.

Tech Talk: Linus Torvalds on git, 2007

After so many years most of us PLC software developers are still ugly and stupid people, wasting our time and our employers’ money fiddling around with zip files with weird names, duplicated content and a software delivery process which is generally very slow and inaccurate.

But it’s not (exclusively) our fault!

Customers, decision makers and stakeholders in general, when choosing your next PLC system, don’t forget asking your vendor a very basic question: is your programming environment Git-compliant?

Otherwise, you are all ugly and stupid at least as me.