1. Schritte - SysMik GmbH

Erste Schritte mit 

Sedona 1.2 

Softwarebeschreibung 

Revision 1

Haftungsausschluss / Impressum 

Diese Beschreibung unterstützt Sie beim Einsatz des Gerätes. Das Dokument wurde 

anhand der beschriebenen Hard- und Software sorgfältig geprüft, eventuelle Abweichungen 

sind jedoch nicht auszuschließen. Für mögliche Fehler in dieser Beschreibung oder in der 

Software selbst wird keine Haftung übernommen. Änderungen der Geräte sowie der 

zugehörigen Dokumente bleiben vorbehalten. Alle Angaben im Dokument werden einer 

regelmäßigen Prüfung unterzogen und notwendige Korrekturen in die nachfolgenden 

Auflagen eingearbeitet. 

Für Kritik und Anregungen sind wir Ihnen dankbar. Nähere Informationen, wie 

weiterführende Beschreibungen, Ausschreibungstexte zu Geräten und über verfügbare 

Software, finden Sie im Internet unter www.sysmik.de. Auf Wunsch senden wir Ihnen diese 

gern zu. 

Die Garantie für das Gerät erlischt bei unsachgemäßer Handhabung, bei Gerätedemontage 

sowie bei Verwendung von nicht durch SysMik für dieses Gerät freigegebener Software. 

Inbetriebsetzung und der Betrieb des Gerätes darf nur unter Beachtung der gültigen 

Sicherheitsbestimmungen und durch qualifiziertes Personal vorgenommen werden. 

SysMik ® und das SysMik-Logo sind eingetragene Warenzeichen der SysMik GmbH Dresden. IPOCS 

ist ein Warenzeichen der SysMik GmbH Dresden. "Networking Together!" © unterliegt dem Copyright 

der SysMik GmbH Dresden. 

Tridium ® , JACE ® , Niagara Framework ® , Niagara AX® und Sedona ® sind eingetragene Marken; 

WorkPlace AX und Supervisor AX sind Marken von Tridium Inc. – registriert in den USA und weiteren 

Ländern. 

Alle anderen in dieser Anleitung gebrauchten Warenzeichen sind eingetragener Besitz der jeweiligen 

Eigentümer. Diese und weitere Warenzeichen sind im Text verwendet, werden jedoch im Interesse der 

Lesbarkeit im Weiteren nicht eigens gekennzeichnet. 

Die Vervielfältigung, Weitergabe dieses Dokumentes, sowie die Verwertung und Mitteilung des Inhaltes 

ist nur mit Einverständnis der SysMik GmbH Dresden gestattet. 

Copyright © 2013 by SysMik GmbH Dresden 

SysMik GmbH Dresden Tel + 49 (0) 351 - 4 33 58 - 0 

Bertolt-Brecht-Allee 24 Fax + 49 (0) 351 - 4 33 58 - 29 

01309 Dresden E-Mail (Verkauf) sales@sysmik.de 

E-Mail (Support) service@sysmik.de 

Germany Homepage http://www.sysmik.de 

2 Erste Schritte mit Sedona 1.2

Inhalt 

Inhalt 

1 Sedona Framework 5 

1.1 Motivation 5 

1.1.1 Ausgangspunkt 5 

1.1.2 Die Herausforderung 5 

1.1.3 Die Antwort 6 

1.2 Bestandteile 7 

1.3 Installation 7 

1.4 Lizenzierung 9 

2 Sedona-Engineering mit WorkPlace AX 10 

2.1 Sedona Manifeste 10 

2.2 Verbindung zum Sedona-Controller 10 

2.2.1 Direktverbindung 10 

2.2.2 Sox Gateway 11 

2.3 Sedona-Tools 11 

2.3.1 Backup/Restore Tool 11 

2.3.2 Application Manager 12 

2.3.3 Kit Manager 13 

2.4 Programmierumgebung 13 

2.4.1 App 13 

2.4.2 Sedona Palette 15 

2.4.3 Views 16 

2.5 Programmierung 17 

2.5.1 Komponenten zur Applikation hinzufügen 17 

2.5.2 Komponenten parametrieren 18 

2.5.3 Komponenten verbinden 19 

2.6 Optimierung 20 

2.6.1 Abarbeitungsreihenfolge 20 

2.6.2 Zykluszeit 21 

2.7 Sicherheit 21 

2.7.1 Konfiguration 21 

2.7.2 Ratschläge 23 

3 Integration von Sedona-Controllern in Niagara AX 24 

3.1 Sedona Network 24 

Erste Schritte mit Sedona 1.2 3

Inhalt 

3.2 Sedona-Gerät 26 

3.3 Sedona Points 27 

3.4 Zentralmanagement 29 

3.4.1 Zentrales Nutzermanagement 29 

3.4.2 Zentrale Zeitsynchronisierung 29 

4 Offline Engineering 30 

4.1 Offline Applikationsprogrammierung 30 

4.1.1 Applikationsdatei erzeugen 30 

4.1.2 SVM auf dem Engineering-PC starten 31 

4.1.3 Verbindungsaufnahme zur SVM 33 

4.1.4 Applikationsprogrammierung 33 

4.1.5 Applikationsdatei speichern 34 

4.2 Offline Integration 34 

5 Textuelle Sedona Programmierung 35 

5.1 Toolbase 35 

5.2 Sedona-Kit 39 

5.3 Sedona-Komponente 39 

5.4 Provisioning 40 

6 Weiterführende Hilfe 43 

7 Anhang A: IO-Ansteuerung im ICS-500 44 

7.1 LocalIo 44 

7.2 Klemmen 45 

7.3 Fehlererkennung 45 

8 Anhang B: Kommunikation 46 

8.1 Modbus 46 

8.2 intesaNet 46 


Sedona Framework 

1 Sedona Framework 

1.1 Motivation 

1.1.1 Ausgangspunkt 

Niagara Framework (engl. Baukasten) ist eine hoch modulare beliebig erweiterbare 

Software zur Realisierung Internetbasierter Automationslösungen. Die JAVAbasierte 

Software läuft auf verschiedenen Plattformen von embedded Controllern 

(INTES) bis zu leistungsfähigen Windows-Servern (Supervisor AX ). Durch 

Hardwareressourcen (Prozessortakt, verfügbarer Speicher) sowie Lizenzmodelle 

(nutzbarer Speicher, Runntime-Units) ergibt sich eine feingranulare 

Leistungsabstufung. Darüber hinaus lassen sich alle diese Steuerungskomponenten 

zu frei definierbaren Hierarchien verbinden, so dass eine hohe Skalierbarkeit mit 

mehreren Freiheitsgraden gegeben ist. So findet sich für jede Aufgabe – von der 

Stand-Alone-Anlagensteuerung bis zu weltweit vernetzten Filialketten - die 

passende Lösung. 

Die modulare Software des Niagara Framework umfasst u.a. 

• Eine homogene Entwicklungsumgebung WorkPlaceAX für die gesamte 

Automationslösung 

• zahlreiche Kommunikationstreiber zur Anbindung bestehender Systeme der 

Feldebene 

• die Anbindung der Enterprise-Ebene über Kommunikations- bzw. 

Datenbanktreiber 

• eine integrierte frei programmierbare Steuerung 

• frei gestaltbare Webseiten für Visualisierung, Parametrierung 

• Systemfunktionen wie Trendlog, Zeitschaltung, Alarme, Reports, Email, 

Backup/Restore 

• Internet-Sicherheitsprotokolle 

1.1.2 Die Herausforderung 

Die angesprochene Modularität und Erweiterbarkeit der Niagara Software wie auch 

deren Plattformunabhängigkeit wird durch die JAVA-Technologie (virtuelle 

Maschine) gewährleistet. Zusammen mit dem erwähnten Funktionsumfang 

entstehen erhebliche Anforderungen an die Hardware. Die verfügbaren embedded 

Steuerungen INTES verfügen über keine eigenen IO; IO muss also immer über ein 

Kommunikationsprotokoll angebunden werden. Gängige Echtzeitanforderungen 

können auf Grund der entstehenden Verzögerungen nicht eingehalten werden. 



Echtzeitfähige Steueralgorithmen konnten bisher nur unterhalb des Niagara 

Frameworks, z.B. in programmierbaren LonMark-Feld-Controllern realisiert werden. 

Das bedeutete jedoch: 

• Ein weiteres Programmiertool neben dem WorkPlace AX 

• Verlust von Engineering-Informationen bei der Integration in Niagara 

• Keine Einbindung in übergeordnete Backup-Strategien 

• Fernzugriff nur über einen extra Zugang. 

1.1.3 Die Antwort 

Sedona heißt die Antwort auf diese Herausforderung. Sedona ist wie ein kleiner 

Bruder des Niagara Frameworks. Es bettet sich nahtlos in die Niagara-Welt ein und 

erweitert dabei den Einflussbereich des Niagara Frameworks nach unten auf die 

Feldebene. Das Engineering erfolgt mit der gleichen Entwicklungsumgebung 

WorkPlace AX und umfasst die grafische Programmierung sowie die Integration von 

Sedona-Controllern in Niagara AX . Eingeschlossen darin sind unter anderem auch 

Backups, zentrale Nutzerverwaltung und Zeitsynchronisierung. Dabei ist Sedona 

speziell für kleine embedded IO-Controller mit wenig Speicher zugeschnitten. Das 

Sedona-Laufzeitsystem steht vollständig als open source zur Verfügung, so dass 

Gerätehersteller Sedona auf ihre Hardware portieren können. Die 

Programmiersprache C garantiert dabei bestmögliche Portabilität. 

Ressourcenhungrige Softwarekomponenten wurden durch schlanke, angepasste 

Lösungen ersetzt. So ist die Sedona Virtual Machine wesentlich kompakter als die 

JAVA VM. Im Gegenzug realisiert Sedona eine echtzeitfähige 

Applikationsausführung mit fester Zykluszeit. 

Das Sox Gateway als Bestandteil von Niagara AX garantiert vollumfänglichen Zugriff 

auf den Sedona-Controller über das Niagara Network hinweg. Das bedeutet, in 

verteilten Lösungen dient eine Niagara Station mit Internet-Verbindung als 

Programmierzugang zu Sedona-Controllern. Auf diese Weise kann der Sedona- 

Controller auch mit der webbasierte Entwicklungsumgebung, die Bestandteil der 

Niagara Station ist, über einen Webbrowser programmiert werden. 

Für den Stand-Alone-Einsatz der Sedona-Controller notwendige Erweiterungen wie 

Visualisierung, Trend, Alarm, Zeitschaltung befinden Sich in Entwicklung. 



1.2 Bestandteile 

Im praktischen Umgang mit Sedona wird man mit zwei Softwarepaketen 

konfrontiert. 

1. Sedona Framework ist ein Open-Source-Projekt und enthält die Sedona Virtual 

Machine, die wir als Gerätehersteller auf unsere Controller portiert haben. Dazu 

kommt die Sedona Programmiersprache incl. Compiler und umfangreicher 

Dokumentation, die Sie für die textuelle Sedona-Programmierung zur Erstellung 

eigener Komponenten und Kits verwenden. 

2. Sedona Framework TXS (Tridium eXtended Services) ist ein Paket von 

Softwarekomponenten, die 

• das Engineering der Sedona-Controller mit WorkPlace AX ermöglichen sowie 

• die Integration von Sedona-Controllern in Niagara AX realisieren. 

Ebenfalls enthalten sind Manifeste, die Fähigkeiten und Funktionen der Sedona- 

Controller beschreiben. 

1.3 Installation 

SysMik vertreibt Produkte auf Basis Niagara Framework und Sedona Framework 

unter dem Namen intesa (INTEgrated Server Architecture): 

• Supervisor AX und Treiber 

• Verschiedene embedded Controller INTES (INTEgration Server) - SysMiks 

Markenname für JACE (Java Application Control Engine) - mit Zubehör 

• Modulare Sedona-Controller ICS-500 mit zahlreichen IO-Klemmen für 

analoge und digitale Ein- und Ausgabe, DALI, MBus, Pulszählung 

• Kompakte Sedona-Controller SCC410, SCC510, SCC520 

Für die Installation von Sedona-Software auf Windows-PCs stellt SysMik zwei 

Setups bereit: 

• Das schlanke intesa Sedona Add-Ons for WorkPlace AX Setup installiert 

das Modul sysmikSedona auf einem PC mit bereits vorhandener 

Supervisor AX Software. Das Setup umfasst 

• Sedona Framework 

• Sedona Framework TXS 

• gerätespezifische Manifeste unserer Controller 

• Hilfe/Dokumentation zu Controllern und Komponenten von SysMik. 



• Das wesentlich umfangreichere intesa Supervisor AX SAX Setup installiert je 

nach Auswahl und Betriebssystem des Rechners 

• intesa Supervisor AX incl. WorkPlace AX für Windows 32 bit oder 

• intesa Supervisor AX incl. WorkPlace AX für Windows 64 bit 

• das Modul sysmikSedona (intesa Sedona Add-Ons für WorkPlace AX ) 

• das Modul sysmikNiLS (Niagara Lighting Solution auf Basis DALI) 

Die Installation von Sedona 1.2 setzt eine vorhandene Installation des Niagara 

Framework Version ab 3.7 voraus. 

Ist noch kein Niagara Framework ab Version 3.7 installiert, starten Sie bitte das 

intesa Supervosor AX SAX Setup. Dieses Setup installiert die aktuelle Version des 

Niagara Frameworks sowie sysmikSedona und kopiert das Sedona-TXS-Paket auf 

Ihren Rechner. Nach Abschluss des Setup ist das Sedona-TXS-Paket über das 

Menü „Tools > Sedona Installer“ zu installieren. 

Bei diesem Vorgang wird WorkPlace AX um Sedona-spezifische Menüeinträge 

erweitert. 

Sollte Niagara Framework bereits auf Ihrem Rechner installiert sein, starten Sie bitte 

das Setup intesa Sedona Add-Ons for WorkPlace AX , welches sysmikSedona 

installiert und das Sedona-TXS-Paket auf Ihren Rechner kopiert. Nach Abschluss 

des Setup ist das Sedona-TXS-Paket über das Menü Tools > Sedona Installer zu 

installieren. 

Die Hilfe „Doc Sedona Installer“ beschreibt den Vorgang des Installierens eines 

Sedona TXS-Bundles im Detail. 



1.4 Lizenzierung 

Die INTES-Controller enthalten bereits die Lizenz zur Integration von Sedona- 

Controllern über das Sedona Network. Bitte beachten Sie, dass das Sedona 

Network – wie jedes andere Netzwerk in Niagara AX – Runtime-Units beansprucht. 

Für Supervisor AX ist eine spezielle Treiberlizenz DSXSED nötig, um Sedona- 

Controller über das Sedona Network direkt zu integrieren. 

Für das Engineering von Sedona-Controllern mit WorkPlace AX ist über die normale 

WorkPlace AX -Lizenz hinaus keine weitere Lizenzierung erforderlich. 


Sedona-Engineering mit WorkPlaceAX 

2 Sedona-Engineering mit WorkPlace AX 

2.1 Sedona Manifeste 

Bei der Entwicklung des Sedona Framework wurde besonderen Wert auf geringe 

Codegröße gelegt. Daher ist auch die Selbstdokumentation der Sedona-Controller 

sehr eingeschränkt. Um mit einem Sedona-Controller kommunizieren und die Daten 

korrekt interpretieren zu können, benötigen die Gegenstellen (Supervisor AX bzw. 

INTES) passende Manifest-Dateien, in denen die Eigenschaften der Komponenten 

in den Kits genau beschrieben sind. 

Supervisor AX besitzt eine Manifest-Datenbank (sedona\manifests). Auf 

www.sedonadev.org existiert eine globale Datenbank von Manifesten. Der „Sedona 

Manifest Manager“ (Menü „Tools > Sedona Manifest Manager“) ermöglicht die 

Pflege der lokalen Manifest-Datenbank durch das Nachladen von Manifesten aus 

der globalen Manifest-Datenbank. Da die lokale Manifest-Datenbank durch die 

intesa- bzw. SysMikSedona-Installation gefüllt wird, wird dieser Manager 

typischerweise nicht benötigt. 

2.2 Verbindung zum Sedona-Controller 

Um einen Sedona-Controller mit WorkPlace AX engineeren zu können, muss eine 

Verbindung zum Sedona-Controller aufgebaut werden. 

2.2.1 Direktverbindung 

Über das Menü „File > Open > Open Device“ erreicht man einen Dialog, in dem man 

die IP-Adresse des Sedona-Controllers sowie Nutzernamen / Passwort einträgt. Im 

Auslieferungszustand haben unsere Sedona-Controller nur einen Nutzer mit Namen 

„admin“ und ohne Passwort. Die Kommunikation erfolgt über das SOX-Protokoll mit 

Standardport 1876. 

Mit der Bestätigung über „OK“ wird die Verbindung aufgebaut und im 

Navigationsbaum von WorkPlace AX entsteht ein neuer Top-Level-Eintrag mit der IP- 

Adresse des Sedona-Controllers. 


2.2.2 Sox Gateway 


Später wird der Sedona-Controller in Niagara AX integriert, d.h. das Gerät wird 

Bestandteil des Sedona Network einer Niagara Station. Dann eröffnet sich ein 

weiterer Engineering-Zugang über das Sox Gateway in der Niagara Station. Der 

Komponentenbaum des Sedona-Controllers wird in den Komponentenbaum der 

Niagara Station eingefügt. Das erhöht die Übersicht im Navigationsbaum von 

WorkPlace AX . 

Die Kommunikation von WorkPlace AX zur Niagara Station erfolgt über FOX bzw. 

FOXS und erst von dort zum Sedona-Controller über SOX. Das ist 

sicherheitstechnisch vorteilhaft. 

Alternativ zur WorkPlace AX enthalten Niagara Stations eine eingebettete 

webbasierte Entwicklungsplatform, die über Webbrowser bedient werden kann. 

Über das Sox Gateway können auf diesem Weg auch Sedona-Controller 

programmiert werden. 

2.3 Sedona-Tools 

Im Navigationsbaum kann man den Baum des Sedona-Controllers expandieren. 

Unterhalb der SOX-Verbindung finden sich die „Sedona Tools“. Mit Doppelklick auf 

die Baum-Einträge werden die Tools gestartet. Eine ausführliche Anleitung zur 

Nutzung der Tools erhalten Sie in der Online-Hilfe unter „Doc Sedona Tools“. 

2.3.1 Backup/Restore Tool 

Mit dem „Backup/Restore Tool“ kann man Backups der Software des Sedona- 

Controllers (Applikation, Scode, SVM) auf dem Engineering-PC anlegen und im 

Bedarfsfall zurück in den Controller laden. Dieses Tool kommt insbesondere beim 

Gerätetausch zum Einsatz. 



2.3.2 Application Manager 

Der „Application Manager“ kann die Applikation des Sedona-Controllers auf dem 

Engineering-PC speichern („Get“) und gespeicherte Applikationen in den Sedona- 

Controller laden („Put“). Diese Funktion wird vor allem verwendet, um Applikationen 

extern bzw. offline zu modifizieren und zu testen, bevor sie wieder in den Sedona- 

Controller geladen werden. 



2.3.3 Kit Manager 

Der „Kit Manager“ erlaubt die Auswahl bzw. Versionsupdates von Kits, die im Scode 

enthalten sein sollen. In die Applikation können nur Komponenten aus Kits eingefügt 

werden, die im Scode enthalten sind. Wenn Sie eigene Kits programmieren, müssen 

sie diese mit dem „Kit Manager“ dem Scode hinzufügen, um die enthaltenen 

Komponenten in der Applikation nutzen zu können. 

2.4 Programmierumgebung 

2.4.1 App 

Im Navigationsbaum kann man den Baum des Sedona-Controllers expandieren. 

Unterhalb der SOX-Verbindung finden sich die „App“. Das ist die Sedona- 

Applikation. Wann immer die Applikation modifiziert wird, erinnert das App-Symbol 

im Baum daran, dass die Applikation gespeichert werden muss. Dazu gibt es im 

lokalen Menü die Aktion „Save“. Weitere wichtige Aktionen sind „Restart“ der 

Applikation und „Reboot“ des Sedona-Controllers. 

„App“ besitzt zudem das Property „Scan Period“, mit dem die Zykluszeit der 

Applikationsausführung eingestellt werden kann. 



Unterhalb von „App“ befindet sich ein Ordner „service“, in dem wichtige Service- 

Funktionen enthalten sind. Der Platform Service „plat“ ermöglicht den Zugriff auf 

plattformspezifische Einstellungen des Sedona-Controllers wie die IP-Adressdaten. 

Der Service „sox“ stellt das Kommunikationsprotokoll SOX für Engineering und 

Integration bereit. Für jegliche Kommunikation über SOX ist eine Anmeldung 

erforderlich. Unter dem Nutzerservice „users“ ist der Administrator-Zugang „admin“ 

enthalten. Mit einem Doppelklick auf „users“ öffnen Sie den User Manager. Hier 

können Sie Nutzer anlegen oder löschen, Rechte vergeben und Passwörter ändern. 



2.4.2 Sedona Palette 

Um Komponenten einer Applikation hinzufügen zu können, muss die „Sedona 

Palette“ über das Menü „Window > Side Bars > Sedona Palette“ aktiviert werden. 

Die Sedona-Palette enthält eine Auswahlbox mit allen im Scode enthaltenen Kits. 

Nach Auswahl des gewünschten Kits werden alle Komponenten des Kits in der 

darunterliegenden Liste angezeigt. Die „Sedona Palette“ ist nur gefüllt, wenn eine 

View einer Sedona-Komponente angezeigt wird. 

Alle Kits mit führendem „SysMik“ im Namen stammen von SysMik: 

• Kits, mit Gebäudeautomations-Funktionen entsprechend VDI 3813 Teil 2 

SysMikBaSensor 

SysMikBaActuator 

SysMikBaOperator 

SysMikBaAppGeneral 

SysMikBaAppLighting 

SysMikBaAppShading 

SysMikBaAppHvac 

• Kits zur Kommunikation 

SysMikModbusServer 

SysMikModbusClient 

SysMikIntesaNet 

Sensorfunktionen 

Aktorfunktionen 

Bedien- und Anzeigefunktionen 

Allgemeine Anwendungsfunktionen 

Anwendungsfunktionen zur Beleuchtungssteuerung 

Anwendungsfunktionen zur 

Verschattungssteuerung 

Anwendungsfunktionen zur Klimasteuerung 

Zugriff auf die je 10.000 lokalen Coils, Discrete 

Inputs, Holding Register und Input Register des 

Modbus TCP-Servers des Controllers 

Zugriff auf Modbus-Datenpunkte fremder Modbus- 

Geräte über Modbus TCP bzw. Modbus RTU 

Netzwerk – Geräte – Punkte auf Basis Modbus 

insbesondere zur Kommunikation zwischen 

Sedona-Controllern aus der intesa-Produktpalette 

• Kits zum Zugriff auf die IO-Klemmen und Bedien- und Anzeigeelemente des 

modularen Controllers ICS-500(M) 

SysMikLocalIo 

SysMikIcsManualCtrl 

LocalIo Netzwerk mit den modularen IO-Klemmen 

Ansteuerung von Bedientasten und Display 

• Platform-Kits mit plattformspezifischen Funktionen für jeden Controller-Typ 

SysMikPlat… 

NV-RAM-Speicherzugriff 

IO der Kompakt-Controller 

Alle Komponenten von SysMik werden in der Hilfe „Doc Sysmik Sedona“ detailliert 

beschrieben. Alle Komponenten der SysMik-Kits haben eine View „SysMik Sedona 

Help“, die die Hilfe zur Komponente anzeigt. 



Kits ohne führenden Firmennamen entstammen dem Sedona Framework von 

Tridium; z.B. 

sys 

func 

hvac 

logic 

math 

pricomp 

sox 

timing 

types 

unsichtbare Systemfunktionen, Folder zur 

Strukturierung 

Signalfunktionen / Signalgeneratoren 

Klimasteuerungsfunktionen 

Logische Funktionen/Gatter 

Arithmetische Funktionen 

Vorrangsteuerung mit 16 Prioritäten 

SOX Kommunikationsprotokoll 

Zeitfunktionen 

Typkonvertierungen, Konstanten 

Eine detaillierte Beschreibung der Sedona Framework Kits ist im Ordner 

„sedona\doc“ der Niagara AX -Installation über „index.html“ erreichbar. 

2.4.3 Views 

Alle Komponenten verfügen über mehrere Views, die über das lokale Menü der 

Komponente ausgewählt werden können. Die Standard-View ist zudem per 

Doppelklick auf die Komponente aktivierbar. 

Das „Sedona Property Sheet“ zeigt alle Slots mit Werten. Sie wird insbesondere 

zur Parametrierung verwendet. 

Das „Wire Sheet“ stellt die untergeordneten Komponenten mit ihren Verbindungen 

grafisch dar und dient der grafischen Programmierung. 

Das „Link Sheet“ zeigt tabellarisch die Verbindungen der Komponente an. 

Das „Slot Sheet“ zeigt alle Slots der Komponente mit ihren Eigenschaften/Facetten 

an. 

Darüber hinaus kann es weitere komponentenspezifische Views geben wie z.B. den 

„User Manager“, die Standardview des „users“ Service. 

Alle Komponenten der SysMik-Kits haben eine View „SysMik Sedona Help“, die die 

Hilfe zur Komponente anzeigt. 



2.5 Programmierung 

Die grafische Sedona-Programmierung besteht aus dem 

• Hinzufügen von Komponenten in die Applikation, dem 

• Konfigurieren der Komponenten und dem 

• Erstellen von Verbindungen zwischen den Komponenten. 

Eine minimale Applikation soll die grundlegenden Schritte verdeutlichen: Ein 

Signalgenerator soll ein stetiges Stellsignal erzeugen, aus dem eine Aktorfunktion 

drei Steuersignale für einen dreistufigen Lüfter generiert. 

2.5.1 Komponenten zur Applikation hinzufügen 

Per Drag aus der „Sedona Palette“ & Drop auf eine Komponente im 

Navigationsbaum können Komponenten aus der „Sedona Palette“ in die Applikation 

eingefügt werden. Jeder Komponenten können weitere Komponenten zugeordnet 

bzw. untergeordnet werden. 

Bitte fügen Sie eine „Folder“ Komponente aus dem Kit „sys“ in ihre „App“ ein. Diese 

Komponente wird ausschließlich zur Strukturierung der Applikation verwendet. 

Geben Sie als Namen „Demo“ ein. 

Mit einem Doppelklick auf „Demo“ öffnen Sie die Standard-View von „Demo“: „Wire 

Sheet“. Fügen Sie nun eine Komponente „Ramp“ aus dem Kit „func“ per Drag aus 

der „Sedona Palette“ & Drop in das „Wire Sheet“ von „Demo“ ein. Der Name „Ramp“ 

kann übernommen werden – die Komponente generiert ein Rampensignal. Nun 

fügen Sie noch eine Komponente „CtrlDriveFan“ aus dem Kit „SysMikBaActuator“ 

hinzu und vergeben den Namen „Fan“. 



2.5.2 Komponenten parametrieren 

Mit einem Doppelklick auf „Ramp“ öffnen Sie die Standard-View von „Ramp“: 

„Property Sheet“. Ändern Sie den Minimalwert „Min“ auf -20.00, damit der Lüfter in 

jeder Periode einige Zeit ausgeschaltet bleibt, die Periodendauer „Period“ auf 120 s 

und den „Ramp Type“ auf „sawtooth“. Geänderte Properties werden rot markiert. 

Übernehmen Sie die Änderungen mit oder der Schaltfläche „Save“. 



Mit einem Doppelklick auf „Fan“ öffnen Sie die Standard-View von „Fan“: „Property 

Sheet“. Ändern Sie die Mindestverweildauer in einer Lüfterstufe „ParCalMinTime“ 

auf 2 s und den „ParCalFanType“ auf „Hierarchy“ – d.h. in Lüfterstufe drei sind alle 

drei binären Ausgangssignale aktiv. Übernehmen Sie die Änderungen mit 

oder der Schaltfläche „Save“. 

2.5.3 Komponenten verbinden 

Mit einem Doppelklick auf „Demo“ öffnen Sie die Standard-View von „Demo“: „Wire 

Sheet“. Verbinden Sie nun Ramp und Fan über eine der folgenden Techniken 

miteinander: 

1. Fahren Sie mit der Maus über den rechten Randbereich (Signalquelle) des 

Property „Out“ von „Ramp“. Der Mauszeiger wird zum Pfeil . Klicken Sie 

nun und halten Sie die Maustaste gedrückt, während Sie mit der Maus auf 

den linken Randbereich (Signalziel) der Signaleinganges „V Set“ von „Fan“ 

fahren. Der Mauszeiger wird wiederum zum Pfeil . Lassen Sie die 

Maustaste los und die Verbindung ist erzeugt. 

2. Fahren Sie mit der Maus über den rechten Randbereich (Signalquelle) der 

untersten weißen Zeile von „Ramp“. Der Mauszeiger wird zum Pfeil . 

Klicken Sie nun und halten Sie die Maustaste gedrückt, während Sie mit der 

Maus auf den linken Randbereich (Signalziel) der untersten weißen Zeile 

von „Fan“ fahren. Der Mauszeiger wird wiederum zum Pfeil . Lassen Sie 

die Maustaste los und ein Dialog zur Definition von Quell- und Zielsignal 

erscheint. Wählen Sie „Out“ von „Ramp“. Alle Slots von „Fan“, die 

hinsichtlich Typ bzw. Schreibbarkeit als Zielsignal nicht in Frage kommen, 

werden grau gefärbt. Wählen Sie „V Set“ von „Fan“. 

Mit „OK“ wird die Verbindung erzeugt. Es sind sämtliche Mischformen aus 1) 

und 2) erlaubt. 



3. Wählen Sie „Link Mark“ im lokalen Menü von „Ramp“. Wählen Sie „Link 

From „Ramp“ im lokalen Menü von „Fan“. Dialog zur Definition von Quellund 

Zielsignal erscheint. Diese Methode eignet sich vor allem dann, wenn 

Verbindungen zwischen Komponenten erzeugt werden sollen, die in der 

Applikationsstruktur verteilt sind und daher nicht gleichzeitig in einem „Wire 

Sheet“ angezeigt werden können. 

Beobachten Sie den Signalverlauf des Stellwertes „V Set“ sowie die drei Lüfter- 

Ausgangssignale. Speichern Sie die Applikation über „Save“ im lokalen Menü von 

„App“. 

2.6 Optimierung 

2.6.1 Abarbeitungsreihenfolge 

Bei der Ausführung (execute) einer Komponente werden immer zuerst die der 

Komponente untergeordneten Komponenten (Children) entsprechend ihrer 

Anordnung im Navigationsbaum von oben nach unten ausgeführt. Im Sinne einer 

schnellen Signalverarbeitung sollte man darauf achten, dass die 

Abarbeitungsreihenfolge, die durch den Navigationsbaum definiert wird, dem 

Signallauf in der Applikation entspricht. Die Anordnung der Komponenten im 

Navigationsbaum wird durch die Reihenfolge der Erzeugung der Komponenten 

initiiert und ist typischerweise suboptimal. Die Applikation benötigt dann mehrere 

Ausführungszyklen, um Ausgänge in Abhängigkeit von Eingangssignalen zu 

steuern. Über den lokalen Menüpunkt „Reorder“ jeder Komponente kann die 

Anordnung der untergeordneten Komponenten an den Signalverlauf – von den 

Eingängen zu den Ausgängen angepasst werden. 



2.6.2 Zykluszeit 

Die Sedona-Applikation wird zyklisch ausgeführt, wobei die Zykluszeit über den Slot 

„ScanPeriod“ der „App“-Komponente definiert wird. Es gibt Fälle, in denen für 

verschiedene Applikationsteile auch unterschiedliche Zykluszeiten erforderlich sind. 

Das gilt z.B. bei Applikationen zur Einzelraumregelung: Während die 

Temperaturregelung mit Zykluszeiten von einigen Sekunden zurechtkommt, verlangt 

die manuelle Lamellenverstellung von Jalousien Zykluszeiten von z.B. 100 ms. Eine 

zyklische Ausführung der gesamten Applikation im 100 ms-Takt aber je nach 

Umfang der Applikation zu einer erhöhten Prozessorlast. Mit dem „RateFolder“ aus 

dem Kit „sys“ kann die Zykluszeit von Applikationsteilen innerhalb des „RateFolder“ 

erhöht werden. Dazu wird im Slot „AppCyclesToSkip“ eine Anzahl von 

Applikationszyklen eingegeben, die abgewartet werden, bevor der Inhalt des 

„RateFolder“ ausgeführt wird. Bei einer Applikationszykluszeit von 100 ms und 9 

„AppCyclesToSkip“ ergibt sich z.B. eine Zykluszeit von einer Sekunde für den Inhalt 

des „RateFolder“. 

2.7 Sicherheit 

Die Sedona-Controller besitzen ein Nutzermanagement, welches über den Service 

„users“ konfiguriert werden kann. Jede Applikation benötigt einen Administrator- 

Zugang mit Vollzugriff auf alle Komponenten der Applikation. Der Standard- 

Administrator-Zugang erfolgt über den Nutzernamen „admin“; das Passwort von 

„admin“ ist leer. 

2.7.1 Konfiguration 

Komponenten können 4 verschiedenen Gruppen angehören, für die ein Nutzer 

jeweils unterschiedliche Zugriffsrechte erhalten kann. Beim Einfügen neuer 

Komponenten in die Applikation werden die Komponenten der „Group 1“ 

zugeordnet. Im „Property Sheet“ der Komponente öffnet ein Klick auf „>>“ hinter 

dem Slot „Meta“ den Dialog zur Modifikation der Gruppenzugehörigkeit. 



Im „User Manager“, der Standard-View des Services „users“, kann per Doppelklick 

auf einen Eintrag der Nutzer-Zugang modifiziert werden. 

Ein neues Passwort muss doppelt eingegeben werden. Ein Klick auf „>>“ hinter 

„Permissions“ öffnet einen Dialog zur Vergabe der Nutzerrechte in jeder der 4 

Gruppen. 

Properties und Actions werden mit der Facette „@operator“ zu Operator-Properties 

bzw. Operator-Actions. Ohne diese Facette sind es Admin-Properties bzw. Admin- 

Actions. Im „Slot Sheet“ einer Komponente kann man die Facetten einsehen. 

Die Nutzerrechte lassen folgende Aktionen zu: 

Operator Read 

Operator Write 

Operator Invoke 

Admin Read 

Admin Write 

Admin Invoke 

Admin User 

Komponenten lesen 

Werte von Operator-Properties lesen 

Werte von Operator-Properties ändern 

Operator-Actions auslösen 

Werte von Admin-Properties lesen 

Verbindungen lesen 

Verbindung von der Komponente erzeugen 

Werte von Admin-Properties ändern 

Komponenten hinzufügen 

Untergeordnete Komponenten sortieren 

Komponente umbenennen 

Komponente löschen 

Verbindungen zu der Komponente erzeugen 

Verbindung zu der Komponente löschen 

Admin-Actions der Komponente auslösen 

Nutzermanagement - nur für „user“-Komponenten: 

„user“ lesen, schreiben, ändern, löschen 



Ein Klick auf „>>“ hinter „Provisioning Permissions“ öffnet einen Dialog zur Definition 

von Aktionen, die vom Nutzer mit den Sedona-Tools ausgeführt werden dürfen. 

Auf http://sedonadev.org/doc/security.html finden Sie eine detaillierte Beschreibung 

der Sicherheitsmechanismen des Sedona Framework. 

2.7.2 Ratschläge 

Im Sinne des Zugriffsschutzes sollten folgende Ratschläge beachtet werden: 

1. Legen Sie neue Nutzer mit zugeschnittenen Rechten und „starken“ Passwörtern 

an. Jeder Bearbeiter sollte seinen eigenen Nutzerzugang haben. 

2. Definieren Sie einen Administrator-Zugang mit allen Rechten und einem 

„starken“ geheimen Passwort. Nutzen Sie den Administrator-Zugang nur in 

Ausnahmefällen. 

3. Löschen Sie den Administrator-Zugang „admin“. 

4. Legen Sie einen Nutzer mit zugeschnittenen Rechten für die Integration in 

Niagara AX an. Ausnahme: Wenn Sie das zentrale Sedona-Nutzermanagement 

von Niagara AX (siehe Abschnitt 3.4.1) aktivieren, muss die Kommunikation über 

einen Administrator-Zugang erfolgen. 


Integration von Sedona-Controllern in NiagaraAX 

3 Integration von Sedona-Controllern in Niagara AX 

Sedona-Controller können als programmierbarer Stanalone-IO-Controller betrieben 

werden. 

Sedona-Controller können über IntesaNet (siehe Abschnitt 8.2) miteinander 

kommunizieren und auf diese Weise in flachen Mehrcontroller-Lösungen zum 

Einsatz kommen. 

Durch die Integration in Niagara AX werden die Sedona-Controller Teil eines 

hochgradig skalierbaren Steuerungssystems und erweitern dieses um eine 

programmierbare IO-Ebene. Wir wollen den Sedona-Controller in einen INTES 

integrieren. 

Eine detaillierte Beschreibung zur Integration von Sedona-Controllern in Niagara AX 

finden Sie in der Hilfe „Doc Sedona Networks“. 

3.1 Sedona Network 

Für die Integration von Sedona-Controllern benötigt der INTES spezielle Software- 

Module. Öffnen Sie eine Platformverbindung zum INTES und installieren Sie im 

Platform-Tool „Software Manager“ das Modul „sedonanet“. Dabei werden einige 

weitere Module, zu denen Abhängigkeiten bestehen mit installiert. 

Im INTES muss ein Sedona-Netzwerk angelegt werden. Öffnen Sie eine 

Stationsverbindung (FOX) und öffnen Sie mit Doppelklick auf „Drivers“ den „Driver 

Manager“. 

Mit „New“ wird ein Dialog zur Treiberauswahl angezeigt. 



Wählen Sie „Sedona Network“ und bestätigen Sie mit „OK“. 

bestätigen Sie mit „OK“. 

Damit der INTES mit dem Sedona-Controller kommunizieren kann, benötigt er die 

passenden Manifeste. Die View „Manifest Manager“ des „SedonaNetwork“ 

ermöglicht den Abgleich der lokalen Manifest-Datenank des Engineering-PC mit der 

Manifest-Datenbank des INTES. Das Platform-Tool „Sedona Environment Manager“ 

geht noch einen Schritt weiter: hier können neben den Kit-Manifesten auch 

Platform-Manifeste und Kits abgeglichen werden. 

Ab Sedona 1.2 können die Sedona-Controller ihre Manifeste mit sich führen. 

Dadurch ist die manuelle Pflege der Manifest-Datenbank nicht mehr erforderlich. 

Der INTES lädt sich die ggf. fehlenden Manifeste bei der ersten Kontaktaufnahme 

vom Sedona-Controller. 

Per Doppelklick auf das „SedonaNetwork“ öffnen Sie die Gerätedatenbank. Mit 

„Discover“ kann nach Sedona-Geräten im Netzwerk gesucht werden. 

Bestätigen Sie mit OK. 



3.2 Sedona-Gerät 

Mit einem Doppelklick auf den zu integrierenden Sedona-Controller wird dieser in 

das „SedonaNetwork“ aufgenommen. 

Vergeben Sie den Gerätenamen „Demo“, geben Sie das und bestätigen Sie mit 

„OK“. 



Expandieren Sie den Baum des Gerätes „Demo“ im „SedonaNetwork“. Unter 

„Sedona Tools“ stehen die bekannten Sedona-Tools zur Verfügung und „Sox 

Gateway“ bietet einen vollwertigen Programmierzugang zum Sedona-Controller. Auf 

diese Weise kann das Engineering des Sedona-Controllers über den INTES hinweg 

erfolgen. Die Kommunikation bis zum INTES erfolgt dabei über FOX und von INTES 

zu Sedona-Controller über SOX. Das kann sicherheitstechnisch interessant sein: für 

FOX gibt es auch eine sichere Variante FOXS, mit der man über unsichere 

Netzwerke kommunizieren kann. So könnte ein zentraler Supervisor AX mit vielen 

entfernten INTES über das Internet sicher kommunizieren; hinter den INTES können 

Sedona-Controller in einem ein lokalen/sicheren vor-Ort-Netzwert angebunden sein. 

3.3 Sedona Points 

Per Doppelklick auf „Points“ erscheint die Datenpunktdatenbank. Betätigen Sie 

„Discover“ 

und wählen Sie als „Discovery Type“ „Online“ aus. 



Der Baum der Sedona-Applikation mit allen Komponenten und Slots wird angezeigt. 

Wählen Sie von „Fan“ die Slots „ioActuator1“, „ioActuator2“, „ioActuator3“ und „vSet“ 

aus ( + Klick) und Betätigen Sie die Schaltfläche „Add“. Damit werden die 

Punkte in Niagara AX integriert und können hier wie jeder andere Punkt behandelt 

werden. 

Achtung! Die Kommunikation erfolgt über die „Point Address“, eine 

Zusammenstellung aus der ID der Komponente und der ID des Slots. Nachträgliche 

Änderungen an der Applikation oder an Komponenten können dazu führen, dass 

sich die Adressinformationen ändern. In diesem Fall muss die „Point Address“ 

angepasst werden. 

Das kann für viele Points sehr effektiv manuell erfolgen: Markieren Sie im „Sedona 

Point Manager“ eine Gruppe von betroffenen Punkten. Per Doppelklick öffnen Sie 

das Bearbeitungsfenster. 

Klicken Sie auf das Symbol hinter „Address“. 



Im Dialog „Batch Search and Replace“ können nun einzelne Adressbestandteile für 

viele Punkte in einem Vorgang ersetzt werden. 

Für einzelne Punkte kann die „Match“-Funktion verwendet werden: Lesen Sie die 

Punkte erneut mit „Discover“ ein, wählen Sie einen betroffenen Slot sowie den 

zugehörigen Punkt und betätigen Sie die Schaltfläche „Match“, um die 

Adressinformation des Slots dem Punkt zuzuweisen. 

3.4 Zentralmanagement 

3.4.1 Zentrales Nutzermanagement 

Man kann Nutzer mehrerer Sedona-Geräte zentral im INTES verwalten. Dazu muss 

die Komponente „SedonaUserManager“ aus der Palette „sedonanet“ in den 

„Service“-Ordner des INTES kopiert werden. Diese Komponente enthält „User 

Service“, in dessen Standard-View Nutzer mit Namen und Passwort definiert 

werden können, sowie „Role Service“, in dessen Standard-View Zugriffsrechte zu 

Nutzerrollen zusammengefasst werden können. 

Mit dem „Sedona Device User Manager“, einer View des „SedonaNetwork“, können 

nun für jedes Sedona-Gerät im „SedonaNetwork“ eine Auswahl der zuvor definierten 

Nutzer zugewiesen werden; jeweils mit einer zugewiesenen Nutzerrolle. 

3.4.2 Zentrale Zeitsynchronisierung 

Sedona-Geräte können Zeitfunktionen enthalten, um Steuerungen z. B. abhängig 

von der Tageszeit oder vom Wochentag zu beeinflussen. In der Sedona-Applikation 

ist dazu ein neuer Service „DateTimeServiceStd“ aus dem Kit „datetimeStd“ nötig. 

Über die Standard-View dieses Services kann die Uhrzeit gestellt werden und es 

gibt Slots, die von Sekunde bis Jahr und Wochentag die Zeitinformationen 

bereitstellen. 

Die Synchronisierung der Uhrzeit von Sedona-Geräten kann vom INTES zentral 

übernommen werden. Dazu muss der Wert des Property „TimeSyncEnabled“ des 

Sedona-Gerätes im „SedonaNetwork“ auf true gestellt werden. Nun wird noch mit 

dem „Time Sync Trigger“ des „Sedona Network“ festgelegt, in welchem Rhythmus 

die Zeitsynchronisierung erfolgen soll. 


Offline Engineering 

4 Offline Engineering 

In Fällen, in denen keine Verbindung zu einem Sedona-Controller besteht, kann das 

Engineering auch offline ausgeführt werden. Eine detaillierte Beschreibung zum 

Offline-Engineering finden Sie in der Hilfe „Doc Sedona Offline Eng“. 

4.1 Offline Applikationsprogrammierung 

Die Offline-Programmierung erfolgt in folgenden Schritten: 

• Passend zum Sedona-Controller (platform) wird eine Applikationsdatei erzeugt 

• Auf dem Engineering-PC wird eine SVM (Sedona Virtual Machine) auf Basis der 

Applikationsdatei gestartet 

• Es wird eine SOX-Verbindung zwischen WorkPlace AX und SVM aufgebaut 

• Die Applikationsprogrammierung erfolgt identisch zur online-Programmierung 

• Die Applikationsdatei wird gespeichert und kann später mit dem Sedona-Tool 

„Application Manager“ in ein Sedona-Controller geladen zu werden. 

4.1.1 Applikationsdatei erzeugen 

Über das Menü „Tools > Sedona New App“ wird der „New App Manager“ gestartet. 

Geben Sie als Name „offline“ ein und bestätigen Sie mit „Next“. 

Im folgenden Dialog kann das Administrator-Kennwort sowie der SOX-Port definiert 

werden. Vergeben Sie ein Passwort, behalten Sie den Standard-Port bei und 

bestätigen Sie mit „Next“. 



Wählen Sie im nächsten Dialog den „Platform Service Type“ 

„SysMikPlatIcs::IcsPlatformService“ aus und geben den „App Device Name“ „Demo“ 

ein. Bestätigen Sie mit Finish. 

Die Applikationsdatei „offline.sax“ wird erzeugt und der Inhalt der Datei – also „App“ 

angezeigt. 

4.1.2 SVM auf dem Engineering-PC starten 

Über das Menü „Tools > Sedona Device Simulator“ wird der „Device Simulator“ 

gestartet. 



Mit einem Klick auf das Verzeichnissymbol neben „Simulator App File“ starten Sie 

den File Browser im Sedona-verzeichnis. Wählen Sie „offline.sax“ aus dem Pfad 

„store/apps“. Über die Schaltfläche „Run“ starten Sie die SVM. Die startet zunächst 

mit Standard-Scode und Standard-Applikation. Automatisch wird der Scode 

passend zu „offline.sax“ erzeugt, die Applikation wird übersetzt und schließlich alles 

in die SVM geladen und diese dann neu gestartet. 

Die SVM läuft nun mit der neu erzeugten, fast leeren Applikation auf dem PC. Alle 

nativen Funktionen wie IO oder Modbus sind allerdings ohne Funktion. 



4.1.3 Verbindungsaufnahme zur SVM 

Das oberste Element im Navigationsbaum ist der Engineering-PC selbst. Wählen 

Sie im lokalen Menü dieses Elementes „Open Device“. 

Bestätigen Sie mit „OK“ und die Verbindung zur lokalen SVM ist erzeugt. 

4.1.4 Applikationsprogrammierung 

Expandieren Sie den Baum der lokalen SOX-Verbindung: er ist identisch zum Baum 

einer SOX-Verbindung eines Sedona-Controllers. Die Programmierung erfolgt 

absolut identisch. Erstellen Sie die Demo-Applikation noch einmal offline. Sie 

können natürlich auch den „Folder“ „Demo“ einfach über die Zwischenablage oder 

Drag & Drop aus der online erstellten Applikation kopieren. 

Speichern Sie die Applikation in der SVM über die Aktion „Save“ von „App“. 



4.1.5 Applikationsdatei speichern 

Öffnen Sie den „Device Simulator“ über das Menü „Tools > Sedona Device 

Simulator“. Über die Schaltfläche „Stop“ wird die SVM gestoppt und die Applikation 

der SVM gespeichert. 

Wählen Sie als Dateinamen „offline.sax“ und Speichern Sie mit „Save“. 

Bestätigen Sie die Sicherheitsabfrage mit „Yes“. 

4.2 Offline Integration 

Auch die Integration eines Sedona-Controllers kann offline, d.h. ohne Verbindung zu 

dem Sedona-Controller erfolgen. Dazu kann man den laufenden „Device Simulator“ 

wie einen Sedona-Controller einlesen und integrieren. 

Über das „Sedona Tool“ „Application Manager“ des Gerätes im „SedonaNetwork“ 

kann man die Applikation im Dateisystem der Station speichern „Get“. Dabei wird 

die gespeicherte Datei dem Gerät im Slot „App File“ zugewiesen. Der Vorteil ist, 

dass ab diesem Zeitpunkt das Einlesen der Punkte mit „Discover“ im „Sedona Point 

Manager“ auch ohne Verbindung zum „Device Simulator“ oder zum Sedona- 

Controller über die Option „From App“ erfolgen kann. 

Um später in den Online-Betrieb zu wechseln, wird nur noch ein Sedona-Controller 

anschlossen, adressiert und über das „Sedona Tool“ „Application Manager“ die 

Applikation geladen. Im „SedonaNetwork“ muss die IP-Adresse des Gerätes an den 

Sedona-Controller angepasst werden. 


Textuelle Sedona Programmierung 

5 Textuelle Sedona Programmierung 

Grafische Programmierung ist sehr einfach, stößt aber auch schnell an Grenzen. 

Einerseits werden grafische Umsetzungen komplexer Applikationen schnell 

unübersichtlich, andererseits ist die zyklische Abarbeitung großer Applikationen 

nicht sehr effektiv. Textuelle Sprachen sind dagegen komplexer, bieten aber 

Sprachmittel, um komplexe Algorithmen übersichtlich und effektiv umzusetzen. 

5.1 Toolbase 

Sedona Framework enthält eine Sprache „Sedona“ sowie einen Compiler „sedonac“ 

für Sedona-Quellcode. Dadurch ist es möglich, eigene Kits mit 

anwendungsspezifischen Komponenten zu programmieren, die nachfolgend in 

Sedona-Applikationen eingefügt werden können. Die im Sedona Framework 

enthaltene Hilfe (sedona\doc\index.html) beschreibt alle Aspekte der Kitentwicklung 

sowie die Sedona Programmiersprache und den Umgang mit dem Compiler. 

Um komfortabel textuell programmieren zu können, empfiehlt sich der Einsatz eines 

Programmiereditors. Wir wollen dafür Eclipse, ein weit verbreitetes freies 

Programmierwerkzeug der Eclipse Foundation, verwenden. 

Da Eclipse auf Java basiert, muss das „Java Runtime Environment“ (JRE) auf dem 

PC installiert sein. Dieses erhalten Sie z.B. von www.java.com/de/download. 

Die aktuelle Version von Eclipse kann über www.eclipse.org/downloads geladen 

werden. Eclipse besitzt kein Setup; stattdessen wird das Archiv einfach in ein 

beliebiges Verzeichnis, z.B. „C:\“ ausgepackt. 

Der Start von Eclipse erfolgt über „C:\eclipse\eclipse.exe“. 

Es muss zunächst ein „Workspace“ ausgewählt werden. Ein Workspace dient der 

Gruppierung mehrerer Eclipse-Projekte und ist hier vorerst nicht relevant. 

Übernehmen Sie den vorgeschlagenen Pfad, markieren Sie „Use this as default and 

do not ask again“, um die Abfrage bei nachfolgenden Starts von Eclipse zu 

umgehen und bestätigen Sie mit „OK“. 

Öffnen Sie den „New Project Wizard“ über das Menü „File > New > Project“. 



Wählen Sie als Projekttyp „General > Project“ und bestätigen Sie mit „Next“. 

Geben Sie den Projektnamen „Sedona“ ein und wählen Sie das Sedona-Home- 

Verzeichis „sedona“ Ihrer Supervisor AX -Installation als Projektpfad aus. Mit „Finish“ 

wird das Projekt erzeugt. Schließen Sie die „Welcome“-Seite. 

Eclipse kennt die Sedona-Programmiersprache nicht. Sedona ist aber der 

Programmiersprache Java sehr ähnlich. Legen Sie den Java-Editor als Editor für 

Sedona Quelltext fest. Wählen Sie im Menü „Windows > Preferences“ und im 

„Preferences“ Dialog „General > Editors > File Associations“. 



Fügen Sie oben mit „Add“ den „File type“ „*.sedona“ hinzu und markieren den neuen 

„File type“ in der Liste. Fügen Sie nun unten mit „Add“ den „Java Editor“ als Editor 

für Sedona-Quelltext-Dateien hinzu. Bestätigen Sie mit „OK“. 

Nun soll noch der Compileraufruf konfiguriert werden, um die Übersetzung des 

Quelltextes aus Eclipse heraus mit Mausklick starten zu können. Dazu wird 

zunächst ein Kit-Quellverzeichnis angelegt, in welchem alle Sedona-Quelltexte des 

zu entwickelnden Kits zusammengefasst werden. Der Verzeichnisname soll dem 

Kit-Namen entsprechen. Der Kit-Name wiederum soll mit dem Firmennamen des 

Herausgebers des Kits beginnen, um Konflikten bei der Nutzung von Kits 

verschiedener Hersteller aus dem Wege zu gehen. Legen Sie im Sedona-Home- 

Verzeichnis „C:\Intesa\Supervisor…\sedona“ ein Verzeichnis „src“ und darin ein 

Verzeichnis „firmaDemo“ an. Wählen Sie im lokalen Menü des Projektes „Sedona“ 

den Menüeintrag „Properties“. Wählen Sie „Builders“ und betätigen Sie die 

Schaltfläche „New“. 



Wählen Sie „Program“ und bestätigen Sie mit „OK“. 

Vergeben Sie den Namen „Sedonac firmaDemo“ und wählen Sie als „Location“ mit 

„Browse File System“ den Pfad zum Sedona-Compiler „sedonac.exe“ im 

Verzeichnis „sedona/bin“. Sedonac erwartet einen Parameter, über den das 

Quelltext-Verzeichnis des zu erzeugenden Kits angegeben wird. Wählen Sie als 

„Working Directory“ mit „Browse File System“ den soeben erstellten Ordner 

„firmaDemo“, schneiden den Inhalt von „Working Directory“ aus und fügen ihn als 

„Argument“ wieder ein. Schließen Sie alle offenen Dialoge mit „OK“. 

Über des Menü „Project > Build All“ kann der Compiler aufgerufen werden. Da das 

Quelltextverzeichnis noch leer ist, generiert der Compiler eine Fehlermeldung. 



Im Sedona-Home-Verzeichnis existiert ein Archiv „src.zip“ mit allen Open-Source- 

Quelltexten des Sedona Framework. Entpacken Sie das Archiv in das erstellte „src“- 

Verzeichnis. Die Quelltexte der Kits stellen gute Codebeispiele dar. 

5.2 Sedona-Kit 

Die Quellen eines Sedona-Kits bestehen aus der Datei „kit.xml“, einer 

Konfigurationsdatei, in der Name, Beschreibung, Version und Abhängigkeiten des 

Kits definiert werden, sowie beliebig viele *.sedona-Dateien, die den Quelltext der 

Sedona-Komponenten enthalten. 

Erstellen Sie die Konfigurationsdatei „kit.xml“ unter „firmaDemo“ mit dem lokalen 

Menü „New > File“. Geben Sie folgenden Text ein: 

 

 

 

 

Danach kann das Kit mit „Project > Build All“ fehlerfrei übersetzt werden. Die 

Ergebnisse finden Sie unter „sedona\manifests\firmaDemo“ (Manifest) bzw. unter 

„sedona\kits\firmaDemo“ (Kit). 

5.3 Sedona-Komponente 

Wir wollen einen einfachen P-Regler zru Temperaturregelung programmieren. Eine 

Komponente wird eine Klasse dadurch, dass sie von „Component“ abgeleitet wird. 

Sie besitzt Properties mit verschiedenen Facetten (@). Die Funktion „execute“ von 

„Component“ wird zyklisch aufgerufen – sie wird überschrieben und nimmt den P- 

Regel-Algorithmus auf. 

Erstellen Sie eine Sedona-Quelltextdatei „TempCtrl.sedona“ und geben Sie 

folgenden Quelltext ein: 

class TempCtrl extends Component 

{ 

@min=1.0 @max=100.0 @unit=Units.kelvin_degrees 

@config property float proportional = 3.0 

@min=5.0 @max=28.0 @unit=Units.celsius 

property float tempSetPoint = 22.0 

@min=-20.0 @max=50.0 @unit=Units.celsius 

property float roomTemp 



} 

@unit=Units.percent 

@readonly property float out 

virtual override void execute () 

{ 

float tempDiff 

float actuate 

tempDiff = tempSetPoint - roomTemp 

actuate = tempDiff / proportional 

if (actuate > 1.0) 

actuate = 1.0 

if (actuate < 0.0) 

actuate = 0.0 

out := actuate * 100.0 

} 

Wieder wird das Kit mit „Project > Build All“ übersetzt. 

5.4 Provisioning 

Nun soll das neue Kit in der Sedona-Applikation verwendet werden. Dazu muss das 

Kit zunächst über das „Sedona Tool“ „Kit Manager“ des Sedona-Controllers 

bereitgestellt (provision), also installiert werden. 



Markieren Sie das Kit „firmaDemo“, bestätigen Sie mit „Next“ und starten Sie den 

Installationsvorgang mit „Finish“. 

Wenn der Vorgang abgeschlossen ist, starten Sie die SVM des Sedona-Controllers 

mit „Restart Device“ neu. Dabei wird die SOX-Verbindung abgebrochen und Sie 

müssen diese erneut öffnen. 

Legen Sie unter „App“ einen „Folder“ „Room1“ an. Legen Sie in diesem Ordner eine 

Komponente „TempCtrl“ aus dem Kit „firmaDemo“ mit Namen „TCtrl“ an. Wechseln 

Sie in die View „Property Sheet“ von „TCtrl“. 



Beobachten Sie die Auswirkungen der Property-Facetten (@min, @max, @unit) 

und testen Sie den Regler-Algorithmus durch Variation der Raumtemperatur. 


Weiterführende Hilfe 

6 Weiterführende Hilfe 

Die englischsprachige Online-Hilfe des WorkPlace AX enthält Dokumente, die das 

Engineering von Sedona-Controllern sowie deren Integration in Niagara AX 

beschreiben. Über das Menü „Help“ kann die Hilfe in einem eigenen Fester geöffnet 

werden. „Help > OnSite“ öffnet das zur aktiven View passende Hilfethema. Das ist 

nützlich, um schnell zur Hilfe von Tools zu gelangen. 

Über Das Menü „Window > Side Bars > Help“ wird die Hilfe integraler Bestandteil 

des Anwendungsfensters von WorkPlace AX . Hilfethemen werden als View 

angezeigt. Folgende Dokumente behandeln Sedona-Themen: 

Doc Sedona Installer 

Doc Sedona Tools 

Doc Sedona Networks 

Doc Sedona Offline Eng 

Doc Sedona Eng Notes 

Doc SysMik Sedona 

Installation von TXS-Paketen 

Sedona Tools 

Integration in Niagara AX 


Manifest Manager 

Beschreibung aller Komponenten der SysMik-Kits. 

Die Komponenten haben eine View „SysMik 

Sedona Help“, die die Hilfe zur Komponente 

anzeigt. 

Das Sedona-Home-Verzeichnis „sedona“ enthält einen Ordner „doc“. Hier finden Sie 

mit „index.html“ den Einstieg in die Hilfe des Open Source Sedona Frameworks. 

Diese gibt einen guten Überblick über das Sedona Framework, beschreibt die 

Sedona-Programmiersprache, den Sedona Compiler „sedonac“ sowie alle Klassen 

der Open-Source-Kits. 

Auf www.sedonadev.org findet man neben der aktuellsten Release des Open- 

Source Sedona Frameworks inkl. Dokumentation auch den Einstieg in 

Diskussionsforen um das Open-Source Sedona Framework. 

Fragen um das Engineering von Sedona-Controllern mit WorkPlace AX und die 

Integration von Sedona-Controllern in Niagara AX werden auf www.niagaracentral.com 

diskutiert. 


Anhang A: IO-Ansteuerung im ICS-500 

7 Anhang A: IO-Ansteuerung im ICS-500 

7.1 LocalIo 

Das ICS-500 ist ein modularer Sedona-Controller. Der Controller kann passend zur 

jeweiligen Aufgabenstellung mit IO-Klemmen zu einer Station erweitert werden. Es 

sind Klemmen mit analogen oder digitalen Eingängen bzw. Ausgängen mit 

unterschiedlicher Kanalzahl sowie Funktionsklemmen (DALI, S0-Zähler) verfügbar. 

Der Zugriff auf die IO in der Sedona-Applikation erfolgt über die Komponenten des 

Kit „SysMikLocalIo“. Eine detaillierte Beschreibung aller Komponenten finden Sie in 

der Hilfe „Doc SysMik Sedona“. 

Für den Zugriff muss eine Komponente „LocalIo“ wird in die Applikation eingefügt 

werden. Sie dient als Container für alle Klemmen-Komponenten, die hier in der 

Reihenfolge eingefügt werden, die der Klemmenreihenfolge der Station entspricht. 

Bei Bedarf kann die Reihenfolge der Komponenten über das lokale Menü von 

„LocolIo“ „Reorder“ dem tatsächlichen Aufbau der Station angepasst werden. 

„LocalIo“ berechnet die Länge der Station sowie die Stromaufnahme und adressiert 

alle untergeordneten Klemmenkomponenten. Über die Action „ReconfigIo“ werden 

Einstellungen der Klemmenkomponenten dem IO-Treiber des Controllers 

übergeben und die Station entsprechend konfiguriert. 


Anhang A: IO-Ansteuerung im ICS-500 

7.2 Klemmen 

Für jede verfügbare Klemme existiert eine Komponente. Die Klemmen- 

Komponenten besitzen je Kanal ein Property, über welche die Eingangssignal 

gelesen bzw. Ausgangssignale geschrieben werden können. 

Einige Klemmen lassen zusätzlich kanalspezifische Konfigurationen zu; z.B. die 

Messbereichseinstellung der analogen Eingangskellen „AI…“. 

Eine zusätzliche View “Ics500 Clamp Manual“ zeigt Datenblatt der Klemme an. 

DALI-Klemmen geben Zugang zu DALI-Netzwerken. Zum Zugriff auf die DALI- 

Teilnehmer existieren Dali-Komponenten, die den DALI-Klemmen-Komponenten 

untergeordnet werden. 

Die Dali-Slave-Komponenten „DaliSCommand“, „DaliSLuxLevel“ und 

„DaliSPresence“ sind nur unterhalb der DALI-Multimaster-Klemme „DALIM__...“ 

nutzbar, um Daten von DALI-Sensoren zugängig zu machen. 

7.3 Fehlererkennung 

Bei der Konfiguration der Station über die Action „ReconfigIo“ der „LocalIo“- 

Komponente werden die Daten der Applikation mit dem erkannten tatsächlichen 

Aufbau der Station verglichen: das Resultat der Prüfung steht am Property „Cfg 

Error“ von „LocalIo“ zur Auswertung bereit; das Property „Cfg Error Terminal“ gibt 

die Klemmennummer, auf die sich der Fehler bezieht, an. Wird ein Fehler erkannt, 

wird die IO-LED des ICS-500 gelb; ohne Fehler wird sie grün. 

Für den Betrieb der Station gibt es zwei Fehlererkennungs-Komponenten, die 

Fehler wie Kabelbruch, Messbereichsverletzungen, Gerätedefekte, DALI-Fehler 

usw. erkennen können. „IoErrorLocal“ kann „LocalIo“ direkt untergeordnet werden 

und gibt den ersten erkannten Fehler in der Station sowie die betroffene Klemmenund 

Kanalnummer aus. 

„IoErrorTerminal“ kann einer Klemmen-Komponente untergeordnet werden. Hier 

kann sogar ein einzelner Kanal der Klemme konfiguriert werden, für den die 

Fehlererkennung durchgeführt werden soll. 


Anhang B: Kommunikation 

8 Anhang B: Kommunikation 

8.1 Modbus 

Die Sedona-Controller können als Modbus TCP Server, Modbus TCP Client und als 

Modbus RTU Master betrieben werden. Jeder Controller hostet 10.000 Coils, 10.000 

Discrete Inputs, 10.000 Holding Register und 10.000 Input Register, die die Sedona- 

Applikation mit Komponenten des Kit „SysMikModbusServer“ lesen und 

beschreiben kann. Es gibt Lese-Komponenten „Get“ und Schreib-Komponenten 

„Set“ für die verschiedenen Datenpunktarten. Es stehen auch Komponenten zur 

Verfügung, die Float bzw. Long-Daten in jeweils zwei benachbarten Registern 

abbilden können. Für alle Komponenten muss die Datenpunktadresse konfiguriert 

werden. 

Mit den Komponenten des Kit „SysmikModbusClient“ wiederum erhält die Sedona- 

Applikation Zugriff auf die Modbus-Datenpunkte anderer Modbus-Geräte. Die 

Kommunikation erfolgt dabei über das Modbus-Protokoll. Es gibt für alle Modbus- 

Datenpunkttypen „Get“-Komponenten und für Coils und Holding Register auch 

„Set“-Komponenten. Es stehen auch Komponenten zur Verfügung, die Float bzw. 

Long-Daten in jeweils zwei benachbarten Registern abbilden können. Für alle 

Komponenten muss eine IP-Adresse des Modbus-Servers, die Portnummer, die 

Unit-Id, die Datenpunktadresse sowie eine Zykluszeit konfiguriert werden. Ist die IP- 

Adresse „0.0.0.0“, dann erfolgt die Kommunikation serielle über Modbus RTU. Die 

Zykluszeit definiert das Polling-Intervall (Get) bzw. die Update-Zykluszeit (Set) an. 

Die Set-Komponenten lösen das Schreiben zusätzlich bei Werteänderungen – also 

ereignisgesteuert aus. 

8.2 intesaNet 

Sedona-Controller der intesa-Produktfamilie können über intesaNet miteinander 

kommunizieren. Die Komponenten des Kit „SysMikIntesaNet“ realisieren eine 

Treiber – Gerät – Punkt-Struktur zur Kommunikation über Modbus TCP. 

Die Komponente „IntesaNet“ ist Container für alle an der Kommunikation beteiligten 

Geräte bzw. Kommunikationspartner. Dies sind „LocalDev“ – das lokale/eigene 

Gerät und mehrere „RemoteDev“. Für die „RemoteDev“-Komponenten muss die IP- 

Adresse des Kommunikationspartners, die Portnummer, die Unit-Id sowie eine 

Zykluszeit konfiguriert werden. 

Nun können in „LocalDev“ und in den „RemoteDev“-Komponenten Datenpunkte 

angelegt werden. In „LocalDev“ werden die Datenpunktadressen automatisch 

beginnend bei 0 fortlaufend vergeben; manuelle Anpassungen sind jederzeit 

möglich. In „RemoteDev“-Komponenten muss die Datenpunktadresse manuell 

konfiguriert werden – passend zu den Datenpunkten in „LocalDev“ des entfernten 

Gerätes. 


Anhang B: Kommunikation 

Beispiel: Der Sedona-Controller mit der IP-Adresse 10.0.7.10 enthält eine 

Applikation mit einem Heizungsregler, der über IO ein Heizventil ansteuert und die 

Raumtemperatur misst. Der Sedona-Controller mit der IP-Adresse 10.0.7.11 gibt 

den Sollwert für die Heizungsregelung vor und überwacht die Raumtemperatur. Der 

Sollwert wird also von 10.0.7.11 nach 10.0.7.10 übertragen und die 

Raumtemperatur von 10.0.7.10 nach 10.0.7.11. 

Um kleine Reaktionszeiten bei geringem Kommunikationsaufkommen zu erreichen, 

ist es also empfehlenswert, ereignisorientiert zu schreiben und nicht zu pollen. Also 

legt man idealerweise ausgehende Daten (zu einem entfernten Gerät) in das 

„RemoteDev“ und Eingangsdaten (von einem anderen Gerät) in „LocalDev“. 

Der Sollwert wird 

• in 10.0.7.10 als „Float“ (nur lesen) im „LocalDev“ mit Datenpunktadresse 0 

angelegt; wird hier also gehostet 

• in 10.0.7.11 als „FloatWr“ (schreibbar) mit Datenpunktadresse 0 (passend zum 

Empfänger) im „RemoteDev“ mit der IP-Adresse 10.0.7.10 angelegt. 

Die Raumtemperatur wird 

• in 10.0.7.11 als „Float“ (nur lesen) im „LocalDev“ mit Datenpunktadresse 12 

angelegt; wird hier also gehostet 

• in 10.0.7.10 als „FloatWr“ (schreibbar) mit Datenpunktadresse 12 (passend zum 

Empfänger) im „RemoteDev“ mit der IP-Adresse 10.0.7.11 angelegt.

1. Schritte - SysMik GmbH

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?