CodeMeter Embedded 2.0 – Neue Funktionen

CodeMeter Embedded geht in eine neue Generation. Wir haben wichtige und interessante neue Funktionen hinzugefügt. Damit verdient die Library den Versionssprung auf CmE 2.0.

Die interne Architektur der CodeMeter Embedded Library wurde überarbeitet und auf den aktuellen Stand gebracht. Damit ist CodeMeter Embedded jetzt in der Lage, mit mehreren Prozessen zeitgleich auf einen gemeinsamen Schlüsselspeicher zuzugreifen. Was sich selbstverständlich anhört und auf Desktop-PCs zum Standard gehört, war in der Embedded-Variante bisher absichtlich nicht enthalten. Der Code sollte möglichst klein sein, es sollte kein Dienst laufen und die CodeMeter Embedded Library direkt als Bestandteil in einem geschützten Programm enthalten sein. Für viele Implementierungen reicht eine einzelne Instanz heute noch aus; immer leistungsfähigere Systeme im Embedded-Markt ermöglichen mittlerweile jedoch eine Erweiterung der Funktionen, so dass sich mehrere geschützte Programme oder Prozesse den Zugriff auf einen CmContainer teilen können. Das ermöglicht auch die vermehrt nachgefragten Einsatzfälle, in denen mehrere Programmteile oder CodeMeter-geschützte Programme unterschiedlicher Hersteller gleichzeitig ablaufen – also der bekannte Desktop-Use-Case übertragen auf leistungsfähige Embedded-Systeme. Die Abstimmung der Prozesse untereinander erfolgt wie üblich für den Anwender völlig transparent innerhalb des Systems im Hintergrund. Ein laufender Dienst oder Daemon ist weiterhin nicht erforderlich. So ist gewährleistet, dass CodeMeter Embedded 2.0 ohne weitere Anpassungen integriert werden kann. Ein Upgrade von CodeMeter Embedded 1.x ist so problemlos möglich. Darüber hinaus macht das intern veränderte Design das Lizenzsystem flexibler und performanter. Wir nennen es License Core.

Nutzung der neuen UFC Firm Codes > 6.000.000

Mit dem Versionssprung auf 2.x wurde auch der Grundstein für die Einführung von License Transfer im CodeMeter Embedded gelegt. Mit der Version 2.0 ist es bereits möglich, vorhandene UFC Firm Codes im Dongle zu nutzen. Damit bleibt die durchgängige Kompatibilität der Firm Codes und Product Codes im ganzen CodeMeter-Universum sichergestellt. Die bereits in der Entwicklung befindliche Version 2.1 wird dann UFC-Lizenzen auch remote updaten können. CodeMeter Embedded 2.1 mit Dongle kann dann als License Transfer Endpoint fungieren. Die License-Transfer-Funktion für CmActLicense wird in Version 2.2 kommen und die Anbindung an die neuen License-Transfer-Funktionen komplettieren. Ein typischer Use-Case in der industriellen Anwendung ist hier zum Beispiel eine Anlage, die beim Kunden aufgebaut und durch einen Techniker in Betrieb genommen wird. Die für einen CodeMeter-geschützten Sensor oder ein CodeMeter-geschütztes PLC-Programm benötigte Lizenz bringt der Techniker auf einem CodeMeter-USB-Dongle mit und überträgt diese dann vor Ort direkt in die Steuerung. Genauso verhält es sich bei einem Reparaturaustausch. Die Anlagen sind in der Regel zwar vernetzt, aber aus Sicherheitsgründen nicht in der Lage, einen externen Dienst wie License Central im Internet zu erreichen. License Transfer vereinfacht es hier dem Anwender, die Lizenzen zu übertragen, ohne das RaC/RaU-Handling über mobile Datenträger abzubilden.

CodeMeter ASIC mit SPI-Schnittstelle

Die im CodeMeter Embedded standardmäßig vorhandene Dongle-Funktionalität wurde um eine weitere Schnittstelle erweitert. Neben USB und dem SD Bus Interface ist jetzt auch die Nutzung von SPI möglich. Hersteller eigener Leiterplattenlayouts können den CodeMeter-Chip als ASIC beziehen und direkt in ihr Layout integrieren. Der CmASIC selbst besitzt zwei Schnittstellen: USB und SPI. Die USB-Spezifikation beschreibt neben der Hardwareschnittstelle auch einen Protokollstack, so dass eine Anbindung mit den Basisfunktionen der meisten Betriebssysteme funktioniert. Der ASIC verhält sich analog zum USB-Dongle entweder wie ein Massenspeicherdevice (MSD Mode) oder wie zum Beispiel eine Tastatur (HID Mode). Letzteres funktioniert daher auch in Umgebungen mit restriktiv gehärteten Umgebungen, die den Zugriff auf Flash-Speicher verbieten und somit die Sicherheit gegen versehentliches Einschleusen von Malware durch Dritte verhindern. Die neu hinzugekommene SPI-Schnittstelle stellt eine Low-Level-Hardwareschnittstelle dar. Dies spart den Umweg über den USB-Stack, spart somit Strom und bindet den Chip direkt an. SPI ermöglicht es, den ASIC in eigenen Implementierungen zu nutzen – unter anderem in sehr schlanken Systemen, die ohne einen USB-Stack auskommen, bis hin zu Bare-Metal-Implementierungen ohne Betriebssystem. Das benötigte Kommunikationsprotokoll ist direkt in CodeMeter Embedded 2.0 integriert, so dass hier keine weiteren Anpassungen seitens des Kunden notwendig sind. Die SPI-Funktion der CodeMeter Embedded Library setzt dann auf die SPI-Kerneltreiber auf, um mit dem CodeMeter ASIC zu kommunizieren.

Was gibt´s sonst Neues?

Die Versionierung von CodeMeter Embedded entspricht jetzt auch der Nomenklatur der anderen Produkte wie License Central oder AxProtector. Die Build-Nummer ist nicht mehr Bestandteil der Version, sondern es werden Major.Minor Releases und dann ein alphanumerischer Zähler verwendet. Somit ist „2.0b“ die aktuelle Version von CodeMeter Embedded.

CodeMeter Embedded 2.0 unterstützt auch leistungsfähige Prozessoren wie ARMv8 mit 64-Bit-Betriebssystemen wie Linux und Windows.

Weiterhin bleibt CodeMeter Embedded kein Produkt von der Stange: Viele Funktionen sind modular ausgeführt. Ziel ist und bleibt, eine möglichst kompakte Software zu liefern. Was nicht benötigt wird, wird nicht mit ausgeliefert. Damit bewegt sich die Größe der Library abhängig von Konfiguration und Plattform im Bereich weniger hundert Kilobyte. Bedingt durch diese Flexibilität wird bei einer Neukundenanfrage auch zunächst das Zielsystem und der Use-Case betrachtet und dann ein individuelles Paket geschnürt. So ist es möglich, dass CodeMeter Embedded mit den Kundenanforderungen individuell skaliert und nicht als monolithischer Block unnötig Systemressourcen belegt. Die möglichen Kombinationen testen wir mit unterschiedlichen Versionen der gängigen Betriebssysteme auf unterschiedlichen Plattformen (siehe Kasten). Damit lassen sich schon die meisten Anwendungsfälle abdecken. Und wo das nicht reicht, kann der Kunde den Quellcode mit der benötigten Toolchain selbst kompilieren und auch an RealTime-Betriebssysteme oder eigene Implementierungen anpassen.

Getestete Kombinationen:

Linux x86 und x86_64
Linux ARMv6hf (RaspberryPi 2)
Linux ARMv6 (RaspberryPi 2, Pandaboard)
Linux ARMv7hf (NanoPi, RaspberryPi 3, Cubietruck,
BeagleBoneBlack)
Linux AARCH ARMv8hf (ODROID-C2)
QNX ARM (Pandaboard)
QNX x86 (Intel Desktop Board D525MW)
VxWorks 6.9 PPC (P2020), x86 (NITX315), ARMv7 (SabreLite IMX6Q)
VxWorks 7 PPC (P2020), x86 (NITX315), ARMv7 (SabreLite IMX6Q), 64 (DELL Optiplex)
Windows x86 und x86_64
Android 5.1 (Raspi3)