Es gibt eine zu Recht weit verbreitete Ansicht, dass ein typischer Entwickler von High-Level-Anwendungssoftware so an die Verfügbarkeit von Systemressourcen und die Weichheit der Echtzeitanforderungen gewöhnt ist, dass man von ihm erwarten kann, den Code zu optimieren, um die zu reduzieren Ressourcenintensität der Anwendung nur in extremen Fällen, wenn sie direkt von Geschäftsinteressen gefordert wird. Dies ist logisch, da bei den Aufgaben der angewandten Automatisierung die Personalressource die teuerste Ressource bleibt. Darüber hinaus lässt die Reduzierung der kognitiven Kosten für das Fummeln mit Bytes die Aufmerksamkeit des Entwicklers für Aufgaben von vorrangiger Bedeutung frei, z. B. die Gewährleistung der Funktionskorrektheit eines Programms.
Es ist selten, wenn es um das umgekehrte Problem geht, das in viel engeren Kreisen von Entwicklern eingebetteter Systeme auftritt, einschließlich Systemen mit erhöhter Fehlertoleranz. Es besteht Grund zu der Annahme, dass die frühen Erfahrungen mit der Verwendung von MCS51 / AVR / PIC so traumatisch sind, dass viele Betroffene während ihrer gesamten Karriere weiterhin Bytes zählen, auch wenn es keine objektiven Gründe dafür gibt.... Dies gilt natürlich nicht für Fälle, in denen harte Preisbeschränkungen die Obergrenze der Ressourcen der Computerplattform (Mikrocontroller) festlegen. Dies gilt jedoch in Fällen, in denen der Preis einer Computerplattform in einer Reihe im Vergleich zu den Kosten des gesamten Produkts und den Kosten für die Entwicklung und Überprüfung seiner nicht trivialen Software unbedeutend ist, wie dies bei Transport und Komplexität der Fall ist industrielle Automatisierung. In diesem Beitrag geht es um die letztere Kategorie von Systemen.
Normalerweise finden Sie hier einen Vorwurf: " Was sind Sie ein Hund ? A MISRA? Und AUTOSAR-Standards? Vielleicht haben Sie die HIC ++ - Handbücher nicht gelesen? Wir haben hier ein ernstes Geschäft und nicht Ihre Schmuckstücke. Der Kran wird fallen." Ihr Kopf, Sie werden völlig tot sein. "Man muss sorgfältig erkennen, dass sich angemessenes Software-Design und funktionale Korrektheitspraktiken in unternehmenskritischen Systemen nicht gegenseitig ausschließen. Wenn Ihre gesamte Software nach dem V-Modell entworfen wurde , werden Sie in diesem Artikel wahrscheinlich etwas Neues lernen, schon allein deshalb, weil Ihre Methodik ein Element unter dem aussagekräftigen Namen Architekturdesign enthält . Ich fordere den Rest der Einbettungskräfte auf, sich zu setzen und über ihr Verhalten nachzudenken.
Stiehl nicht
, , ? :
, , . , , , .
" "? . , - , . , , MISRA- () .
, , , . , , , Boeing 737MAX ( , ). -, ( ) , . - .
, :
-, .
, - , .
Utils helpers, .
: , ; , ; , , . , -, , , .
: Mbed, Arduino, .. , , . CLion ; . , - . , - , .
( ) ; ( ). , . . , , . , , :
, ! , Mbed , , . , ! , , ! , . , , CAN , , Mbed.
, , , . , , : , - . , — , . , , - , 1% .
, . , .
UAVCAN (Uncomplicated Application-level Vehicular Computing And Networking), () Ethernet, CAN FD RS-4xx. - DDS ROS, , , , baremetal .
UAVCAN - — DSDL — , -. REST , XMLRPC, . — , - — , , UAVCAN.
, " , ". DSDL:
# Calibrated airspeed
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.velocity.Scalar.1.0 calibrated_airspeed
float16 error_variance
# Pressure altitude
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.length.Scalar.1.0 pressure_altitude
float16 error_variance
# Static pressure & temperature
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.pressure.Scalar.1.0 static_pressure
uavcan.si.unit.temperature.Scalar.1.0 outside_air_temperature
float16[3] covariance_urt
# The upper-right triangle of the covariance matrix:
# 0 -- pascal^2
# 1 -- pascal*kelvin
# 2 -- kelvin^2
, (, , ). , , , .
, , . - . , , , , , .
" " — — " , , ". , , , : , , . , : , . - :
uint16 differential_pressure_reading uint16 static_pressure_reading uint16 outside_air_temperature_reading
, , , , , , . , , . .
-, , — . , , , , .
, . , , . , , .
, .
, , , . , , , : UAVCAN Interface Design Guidelines. , , , - .
. DS-015 ( NXP Semiconductors Auterion AG) , , , . .