Simple Field Bus Protocol (SFBP)
Un protocollo di comunicazione leggero e a basso consumo per l'automazione distribuita.
Panoramica
Il Simple Field Bus Protocol (SFBP) è un protocollo personalizzato sviluppato per supportare la comunicazione peer-to-peer e basata su eventi su reti RS-485 o radio a sub-GHz. Progettato con semplicità, robustezza e determinismo in mente, SFBP consente una messaggistica affidabile tra nodi autonomi in sistemi distribuiti — con un minimo impatto in termini di larghezza di banda e carico di elaborazione.
Caratteristiche
- Supporta fino a 126 dispositivi per segmento di rete
- Supporta indirizzamento broadcast e diretto
- Messaggi sia sincroni (connessi) che asincroni (datagramma)
- Efficiente per piccoli payload; supporta la frammentazione per dati più grandi
- Multi-master: comunicazione peer-to-peer senza coordinatore centrale
- Indipendente dall’hardware: funziona su RS-485 o radio sub-GHz
- Formato pacchetto ultra-compatto: solo 11 byte per pacchetto
Applicazioni
- Controllo distribuito, tipicamente su RS-485 e/o radio a 833 MHz
- Automazione locale senza nodo master
- Messaggistica basata su eventi in automazione industriale e degli edifici
Documentazione e Software del Protocollo
Scarica i documenti ufficiali e le note tecniche:
- Specifiche SFBP (PDF) (include Formato dei Messaggi e Diagrammi Temporali)
- Note di Implementazione & Esempi
Scarica il software:
- SFBP.dll - Libreria dinamica Windows (32-bit) SFBP.zip (comprende documentazione ed esempi).
SFBP vs Modbus
Sebbene Modbus sia ancora ampiamente utilizzato nei sistemi industriali legacy, SFBP offre un design più moderno e flessibile, pensato per l’automazione distribuita e basata su eventi. Ecco un confronto:
| Caratteristica | SFBP | Modbus |
|---|---|---|
| Copertura Modello OSI | Dal livello Data Link fino a parte dell’Application; flessibile per estensioni personalizzate | Principalmente Application e Presentation; presuppone stack fisico master-slave |
| Topologia | Multi-master, peer-to-peer (distribuita) | Master-slave (centralizzata) |
| Stile di Comunicazione | Supporta messaggi connessi (con ACK) e datagrammi (non connessi) | Solo richiesta/risposta (il master deve sempre interrogare) |
| Supporto Broadcast | Sì (nativo) | Limitato (dipende da codici funzione e implementazione) |
| Ottimizzazione Dimensione Messaggi | Molto compatto: pacchetti da 11 byte | Variabile, spesso maggiore a seconda del codice funzione |
| Livello Fisico | Indipendente (RS-485, RS-232, radio, ecc.) | Generalmente RS-232/RS-485; Ethernet nella variante Modbus TCP |
| Estensibilità | Logica applicativa, sessioni e frammentazione personalizzabili dallo sviluppatore | Struttura rigida con codici funzione fissi |
| Uso Ideale | Sistemi di controllo distribuiti e basati su eventi | Controllo industriale legacy basato su polling |
Conclusione
SFBP è stato progettato da zero per supportare ambienti moderni di automazione distribuita in cui i dispositivi devono agire in modo indipendente, rispondere rapidamente agli eventi e scalare senza colli di bottiglia centralizzati. Sebbene Modbus possa ancora essere utile per integrazioni legacy, SFBP rappresenta un’alternativa più snella e adattabile per sistemi peer-to-peer, intelligenza distribuita e applicazioni di automazione di nuova generazione.
SFBP DLL Note di Implementazione
Nel file ZIP sono disponibili esempi e documentazione per l'utilizzo della libreria dinamica SFBP in C/C++, Visual Basic e C#.
Qui vengono fornite informazioni sui concetti di funzionamento.
Come Funziona SFBP DLL
Quando si chiama OpenCOM è necessario fornire un argomento hWnd. Questo perché la DLL inizia a subclassare l’handle della finestra fornita.
In background, SFBP.DLL avvia un thread in modalità apartment e poi si registra per ricevere messaggi privati che Windows invierà all'applicazione, i
quali a loro volta vengono intercettati dalla DLL tramite subclassing.
Quando il canale di comunicazione deve essere chiuso, chiamando CloseCOM il thread viene automaticamente distrutto e le risorse allocate vengono rilasciate.
Questo impedisce inoltre alla DLL di richiamare l'applicazione host (non vengono più generati eventi). A questo punto, l'applicazione dovrebbe chiamare SetClientHWND(0)
per annullare il subclassing della finestra.
Pertanto, prima di chiamare OpenCOM bisogna assicurarsi che il WinForm sia effettivamente caricato, in modo che l’handle sia valido. Inoltre, prima di chiamare OpenCOM, è necessario chiamare anche SetCallbackEvents per registrare le proprie funzioni delegate (vedi InitializeCallbacks più sotto).
Esempio con C#:
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
// Force handle creation up front:
var h = this.Handle;
}
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
// Register callbacks first
NSCCOMhelper.InitializeCallbacks();
// OpenCOM wants an HWND to subclass:
int result = NSCCOMhelper.OpenCOM((int)this.Handle);
if (result != 0)
MessageBox.Show("Failed to open COM: " + result);
}
protected override void OnFormClosing(FormClosingEventArgs e)
{
// Cleanly close communication and unsubscribe subclass:
NSCCOMhelper.CloseCOM();
NSCCOMhelper.SetClientHWND(0); // Stop thread, release buffers, etc.
base.OnFormClosing(e); // Unsubclass the window
}
}
Ulteriori esempi sono disponibili nella documentazione inclusa nel ZIP file.