There is a deservedly widespread point of view that a typical developer of high-level application software is so accustomed to the availability of system resources and the softness of real-time requirements that one can expect from him to optimize the code in order to reduce the resource intensity of the application only in extreme cases when it is directly required by business interests. This is logical, because in the tasks of applied automation, the human resource remains the most expensive resource. Moreover, reducing the cognitive cost of fiddling with bytes leaves the developer's attention free for tasks of primary importance, such as ensuring the functional correctness of a program.
It is seldom when it comes to the reverse problem that occurs in much narrower circles of embedded systems developers, including systems with increased fault tolerance. There is reason to believe that the early experience of using MCS51 / AVR / PIC is so traumatic that many sufferers then continue to count bytes throughout their careers, even when there are no objective reasons for this.... This, of course, does not apply to cases where hard price constraints set the ceiling on the resources of the computing platform (microcontroller). But this is true in cases where the price of a computing platform in a series is insignificant in comparison with the cost of the product as a whole and the cost of developing and verifying its non-trivial software, as is the case in transport and complex industrial automation. This post is about the latter category of systems.
Usually here you can find a reproach: " What are you a dog A MISRA? And AUTOSAR standards? Maybe you haven't read the HIC ++ manuals? We have a serious business here, and not your trinkets. The crane will fall on your head, you will be completely dead. " one must carefully realize that adequate software design and functional correctness practices in mission-critical systems are not mutually exclusive. If all your software is designed according to the V-model , then you probably will learn a little new in this article, if only because your methodology contains an item under the meaningful name of architecture design . I urge the rest of the embeders to sit down and think about their behavior.
Do not steal
, , ? :
, , . , , , .
" "? . , - , . , , 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) , , , . .