Robotik-Design und Entwicklung Dienstleistungen

Der Entwicklungslebenszyklus reicht von einem definierten Problem bis zu einem Robotersystem, das in Ihrer Produktion arbeitet. Wir beginnen mit den Anforderungen und der Sicherheitskategorie, gehen dann zur Mechanik- und Elektronikkonstruktion über und bauen einen Prototyp in unserem Labor. Firmware und Steuerungssoftware folgen auf dieser Hardware, und die Integrationstests finden in Ihrer realen Produktionsumgebung statt.

Die letzte Phase ist die Inbetriebnahme und das Support-Modell, das Firmware-Versionen und die Veralterung von Komponenten abdeckt. Jede Phase endet mit etwas, das Sie in Betrieb sehen können, sodass Sie ein demonstriertes Verhalten abnehmen.

Vier, und das Schwierige ist, sie dazu zu bringen, sich zu einigen. Die Mechanik bestimmt die Kinematik und das Gehäuse. Die Elektronik macht daraus Platinen und Leistungsteile. Die Firmware lässt die Echtzeit-Steuerungssysteme darauf laufen. Die Steuerungssoftware kümmert sich um Bewegungsplanung und Wahrnehmung und gibt dem Bediener etwas an die Hand, mit dem er arbeiten kann.

Die meisten Verzögerungen entstehen an den Schnittstellen. Ein sauberes mechanisches Konzept erweist sich auf einer vierlagigen Platine möglicherweise als nicht verdrahtbar, oder ein Regelkreis, der sich in der Simulation unauffällig verhielt, verpasst auf einem Mikrocontroller, der bereits mit der Bedienung von Encoder-Interrupts ausgelastet ist, seine Frist. Wenn verschiedene Zulieferer für unterschiedliche Ebenen zuständig sind, kommt die Integrationsrechnung am Ende – deshalb behalten wir alle vier in einem Team.

Design definiert, was die Maschine sein wird, und Development baut sie. Design umfasst Kinematik, Aktuarauswahl, Elektronikarchitektur und das Sicherheitskonzept und übergibt Zeichnungen und Schaltpläne mit einem Plan, anhand dessen man bauen kann. Development ist PCB-Layout, Firmware, Steuerungssoftware und die Prüfstände, die beweisen, dass es funktioniert.

Wir tun beides, und das ist wichtig, denn bei der Entwicklung von Robotikprodukten kommen die meisten teuren Überraschungen von einer Designentscheidung, die niemand mit der Realität der Implementierung abgeglichen hat.

Ja, und die Tatsache, dass Hardware- und Softwareentwicklung in einem Team sitzen, ist meistens der Grund, warum die Leute uns anrufen. Ein Roboterentwicklungsunternehmen, das nur eine Ebene abdeckt, muss den Rest vergeben, und genau daher kommen die Integrationskosten. Hier entwirft dieselbe Organisation die Elektronik und schreibt die Firmware, und die Steuerungssoftware kommt von derselben Gruppe, sodass eine Schnittstellenänderung in einem Gespräch geklärt wird statt durch einen Änderungsantrag.

Sie können uns auch nur für eine einzige Ebene hinzuziehen. Viele Teams fangen mit Firmware für eine bereits existierende Maschine oder mit der Neuentwicklung einer Steuerungssoftware an und weiten den Bereich dann aus, sobald wir zusammengearbeitet haben.

Ja. Wenn die Mechanik bereits feststeht, können wir nur die Embedded-Schicht übernehmen: Echtzeitsteuerung auf einem RTOS oder Embedded Linux sowie die Treiber und die darunterliegenden Platinen. Teams kommen normalerweise auf diesem Weg zu uns, wenn eine Maschine bereits existiert und ihre Firmware eher neu aufgebaut als geflickt werden muss.

Wir beginnen mit dem Lastspiel und Ihrer Risikobeurteilung, denn diese beiden bestimmen die Sicherheitskategorie und den Großteil der Hardware. Von dort aus legen wir den Antriebsstrang und den Regler aus und entwickeln anschließend die Bewegungssoftware passend zu den Taktzeiten, mit denen Ihre Anlage tatsächlich läuft.

Feldbus läuft in der Regel auf EtherCAT oder CANopen hinaus, je nachdem, was die Anlage bereits hat. Die Sicherheit folgt IEC 62443, und die Validierung umfasst Dauerläufe sowie EMV-Präkonformität in unserem Labor, damit keine Überraschungen auftauchen, sobald eine externe Stelle einbezogen wird.

Ein Qualitätssystem, bevor auch nur eine Zeile Code geschrieben wird. Wir arbeiten nach ISO 13485 und erstellen IEC-62304-Dokumentation während der Software-Entwicklung, mit Risikomanagement nach ISO 14971 und elektrischer Sicherheit nach IEC 60601-1.

Der Teil, den Teams meist unterschätzen, ist die Rückverfolgbarkeit von der Anforderung zum Test. Sie während des Prozesses aufzubauen, kostet nur einen Bruchteil dessen, was die Rekonstruktion für eine 510(k)- oder MDR-Einreichung erfordert, weshalb wir die Designakte vom ersten Tag an als Liefergegenstand behandeln.

Steuerungs-Code ist entweder Rust oder C++, je nachdem, wie viel Sicherheitsgewicht er hat und was man bereits besitzt, und läuft auf einem RTOS wie Zephyr oder FreeRTOS oder auf Embedded Linux, das mit Yocto erstellt wurde. Weiter oben ist es ROS 2, mit micro-ROS auf der Mikrocontrollerseite und Nav2 oder MoveIt 2, wo sie zur Aufgabe passen.

Für die Wahrnehmungsverarbeitung nutzen wir OpenCV und PyTorch, bereitgestellt über TensorRT oder ONNX Runtime auf Jetson oder einem vergleichbaren Modul. Auf der Hardwareseite entwickeln wir in Altium Designer rund um STM32, NXP i.MX oder das Compute-Modul, auf das Sie bereits standardisiert sind.

Sicherheit ist eine Architekturentscheidung, deshalb treffen wir sie zuerst. Wir leiten den erforderlichen Performance Level aus Ihrer Risikobeurteilung ab und implementieren die Sicherheitskette dann in Hardware, wo immer ein Softwarefehler niemals das Einzige sein darf, das zwischen einem Menschen und einer bewegten Achse steht.

Für Updates wird jedes Release als signiertes Image auf A/B-Partitionen ausgeliefert, und ein Watchdog setzt jedes Gerät zurück, das nach dem Umschalten seine Integritätsprüfung nicht besteht. Rollouts erfolgen in Kohorten, sodass ein fehlerhaftes Release bei der ersten Gruppe gestoppt wird. Die Schlüssel liegen in einem Hardware-Root-of-Trust, und wir testen den Update-Pfad während der Validierung auf Produktionshardware, denn ein Rollback, das noch nie ausgeführt wurde, ist ein Rollback, das man nicht hat.