Existe un punto de vista merecidamente extendido de que un desarrollador típico de software de aplicación de alto nivel está tan acostumbrado a la disponibilidad de los recursos del sistema y a la suavidad de los requisitos en tiempo real que se puede esperar de él para optimizar el código para reducir la intensidad de recursos de la aplicación solo en casos extremos cuando los intereses comerciales lo requieran directamente. Esto es lógico, porque en las tareas de automatización aplicada, el recurso humano sigue siendo el recurso más caro. Además, la reducción del costo cognitivo de manipular bytes deja libre la atención del desarrollador para tareas de importancia primordial, como garantizar la corrección funcional de un programa.
Rara vez ocurre cuando se trata del problema inverso que ocurre en círculos mucho más estrechos de desarrolladores de sistemas integrados, incluidos los sistemas con mayor tolerancia a fallas. Hay razones para creer que la experiencia inicial de usar MCS51 / AVR / PIC es tan traumática que muchos pacientes continúan contando bytes a lo largo de sus carreras, incluso cuando no hay razones objetivas para ello.... Esto, por supuesto, no se aplica a los casos en los que las restricciones de precio estrictas establecen el límite máximo de los recursos de la plataforma informática (microcontrolador). Pero esto es cierto en los casos en que el precio de una plataforma informática en una serie es insignificante en comparación con el costo del producto en su conjunto y el costo de desarrollar y verificar su software no trivial, como es el caso de transporte y complejos. automatización industrial. Esta publicación trata sobre la última categoría de sistemas.
Por lo general, aquí puedes encontrar un reproche: " ¿Qué eres un perro A MISRA? ¿Y los estándares de AUTOSAR? ¿Quizás no has leído los manuales de HIC ++? Tenemos un negocio serio aquí, y no tus chucherías. La grúa se caerá tu cabeza, estarás completamente muerto " . Uno debe darse cuenta cuidadosamente de que el diseño de software adecuado y las prácticas de corrección funcional en sistemas de misión crítica no son mutuamente excluyentes. Si todo su software está diseñado de acuerdo con el modelo V , entonces probablemente aprenderá algo nuevo en este artículo, aunque solo sea porque su metodología contiene un elemento con el nombre significativo de diseño de arquitectura . Insto al resto de los embebidores a que se sienten y piensen en su comportamiento.
No robes
, , ? :
, , . , , , .
" "? . , - , . , , 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) , , , . .