Il y a un point de vue à juste titre largement répandu selon lequel un développeur typique de logiciel d'application de haut niveau est si habitué à la disponibilité des ressources système et à la douceur des exigences en temps réel que l'on peut attendre de lui pour optimiser le code afin de réduire le l'intensité des ressources de l'application uniquement dans les cas extrêmes lorsqu'elle est directement requise par les intérêts commerciaux. C'est logique, car dans les tâches d'automatisation appliquée, la ressource humaine reste la ressource la plus chère. De plus, la réduction du coût cognitif de la manipulation d'octets laisse l'attention du développeur libre pour les tâches de première importance, comme assurer l'exactitude fonctionnelle d'un programme.
Il est rare que le problème inverse se produise dans des cercles beaucoup plus étroits de développeurs de systèmes embarqués, y compris des systèmes avec une tolérance aux pannes accrue. Il y a des raisons de croire que l'expérience précoce avec MCS51 / AVR / PIC est si traumatisante que de nombreux patients continuent à compter les octets tout au long de leur carrière même s'il n'y a pas de raisons objectives à cela.... Ceci, bien entendu, ne s'applique pas aux cas où des restrictions de prix strictes fixent le plafond des ressources de la plate-forme informatique (microcontrôleur). Mais cela est vrai dans les cas où le prix d'une plateforme informatique en série est insignifiant par rapport au coût du produit dans son ensemble et au coût de développement et de vérification de son logiciel non trivial, comme c'est le cas dans les transports et les complexes. l'automatisation industrielle. Cet article concerne cette dernière catégorie de systèmes.
Habituellement, vous pouvez trouver ici un reproche: " Qu'est-ce que tu es un chien A MISRA? Et les normes AUTOSAR? Peut-être que vous n'avez pas lu les manuels HIC ++? Nous avons une affaire sérieuse ici, et pas vos bibelots. La grue va tomber sur votre tête, vous serez complètement mort. »Il faut bien comprendre que la conception de logiciels adéquats et les pratiques d'exactitude fonctionnelle dans les systèmes critiques ne s'excluent pas mutuellement. Si tous vos logiciels sont conçus selon le modèle en V , vous en apprendrez probablement un peu plus dans cet article, ne serait-ce que parce que votre méthodologie contient un élément sous le nom significatif de conception d'architecture . J'exhorte le reste des intégrateurs à s'asseoir et à réfléchir à leur comportement.

Ne pas voler
, , ? :
, , . , , , .
" "? . , - , . , , 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) , , , . .
- uavcan_ru forum.uavcan.org.