The current draft guarantees that all UAVCAN transports support at least eight distinct priority levels. We should consider defining human-friendly names for each of them in order to aid human developers when choosing priority levels to use in their systems, and to remove confusion when dealing with inverted priority numbers (such as those used in CAN, where lower values preempt higher values). The current draft of the specification already contains such mnemonics, but it’s been decided earlier that their names are seriously lacking and better alternatives should be searched for.
Here is my proposition (I am not particularly happy about it, but my thesaurus is failing me):
Immediate (highest)
Über
Extra high
High
Normal
Low
Extra low
Background (lowest)
The Normal priority level is intentionally shifted down in order to make prioritization of time-sensitive data more flexible, whereas low-priority data are expected to be less sensitive to that.
Note that “application” levels are provided to ensure that a mature system can insert new priorities above or below existing priorities used in the standard.
0 (reserved for applications)
1 Command – The priority to use for anything that is a time-sensitive command.
2 High
3 (reserved for applications)
4 Nominal
5 Low – This level and above are valid for an operational/active/un-safe systems.
6 Maintenance – This level and below should never be used by an operational/active/un-safe system.
7 (reserved for applications)
The standard currently does not really assign any fixed priority levels for any function (and I don’t think it ever will?), so I don’t see any use to the distinction between “standard” priority levels and application-specific ones – they are all application-specific. Considering that, does it really make sense to reserve any of them? As I see the problem, it’s rather a question of decent naming rather than architecture.
I don’t like the name Command, because it also might be some other kind of data (e.g. a state estimate), and I don’t like Maintenance, because it also might be used for very low-priority data related to slow processes (e.g., fuel temperature).
From the two available propositions, I like only Background, Low, Nominal, and High. Perhaps we should just look for replacements for Extra*, Über, and Immediate?
If we are going to define mnemonics for these levels then I’d propose providing guidance in a non-normative section of the specification that has some opinion about their use otherwise providing any definition is useless and we could just skip this.
Here’s a revised proposal:
0 Critical (highest) – Reserved for alarms and overrides; any message that should normally not be sent but when sent must delivered even on a full loaded bus. 1 Immediate – The priority to use for any message that is time-sensitive. 2 Fast – The priority to use for a time-sensitive message that can tolerate being delayed by an Immediate. 3 High – Messages of generally high importance but which are tolerant to being delayed by other messages. 4 Nominal (default) – Messages of nominal importance which are tolerant to being delayed by other messages. This is a good default priority to use if a message has no special requirements. 5 Low – Messages of generally low importance which are tolerant to being delayed by other messages. 6 Background – Messages that are normally used in an operational system but which can tolerate being greatly delayed by other messages. 7 Diagnostic (lowest) – Messages that must never delay another message and that must tolerate never being received on a fully-loaded bus. This level is good for debug or configuration messages that should not be used by a system while in normal use.
Let’s bikeshed some more. I would like to suggest a few replacements:
Critical – If this level is reserved for exceptional traffic and is not intended to be used normally, would it not be better to name it “Exceptional”? Seems to reflect the purpose better.
Fast – how does it compare against “High”? Are there any better words that make the relationship between this level and “High” clearer? Or is it already as clear as it gets and I’m just complaining for no reason?
Background – unless it is the lowest one, this name doesn’t make sense; we can’t call it “background” unless it’s all the way in the back, can we? Or is my English failing me here? Can we call this level Delayable or Postponable instead?
Diagnostic – I am generally okay with this name, but can we please consider other options too: “Background” (because it’s the lowest one) and “Dispensable” (to emphasize that timely delivery not guaranteed)?
I think we’re converging. My thinking is that this non-normative section is addressed to a bus architect who has to do the loading calculations and ensure that all possible states are valid for a system. Let me refine my proposal with that actor in mind:
Exceptional - The bus designer can ignore these messages when calculating bus load since they should only be sent when a total system failure has occurred. For example, a self-destruct message on a rocket would use this priority (Since there will be no CAN bus after the message is sent the bus load is irrelevant, kaboom!). Another analogy is an NMI on a microcontroller.
Immediate - Immediate is a “high priority message” but with additional latency constraints. Since exceptional messages are not considered when designing a bus, the latency of immediate messages can be determined by considering only immediate messages.
Fast - Fast and immediate are both “high priority messages” but with additional latency constraints. Since exceptional messages are not considered when designing a bus, the latency of fast messages can be determined by considering only immediate and fast messages.
High - High priority messages are more important than Nominal messages but have looser latency requirements than fast messages. This priority is used so that, in the presence of rogue nominal messages, important commands can be received. For example; one might envision a failure mode where a temperature sensor starts to load a vehicle bus with nominal messages. The vehicle remains operational (for a time) because the controller is exchanging fast and immediate messages with sensors and actuators. A system safety monitor is able to detect the distressed bus and command the vehicle to a safe state by sending high priority messages to the controller.
Nominal - This is what all messages should use by default. Specifically the NodeStatus should use this priority.
Low - Low priority messages are expected to be sent on a bus under all conditions but cannot prevent the delivery of nominal messages. They are allowed to be delayed but latency should be constrained by the bus designer.
Slow - Slow messages are low priority messages that have no time sensitivity at all. The bus designer need only ensure that, for all possible system states, these messages will eventually be sent.
Optional - These messages might never be sent (theoretically) for some possible system states. The system must tolerate never exchanging optional messages in every possible state. The bus designer can ignore these messages when calculating bus load. This should be the priority used for diagnostic or debug messages that are not needed on an operational system.
The recommendations seem very sensible. I am going to include them into the spec (we will review that separately later).
I am not perfectly happy about Fast and Slow, but I don’t have anything drastically better to propose either, so I guess it will have to stay unless someone else comes up something different.
This looks great for a non-normative portion of the specification. I’m OK including them as is, but I’ve also included a couple of small nits/suggestions that came to mind:
Should we change “optional” to “best effort” and keep the text as is?
Should we change “slow” to “insensitive” and keep text as is?
Should we express that performance of the system may be degraded for latency for delayed “Fast” messages?
I don’t like “fast” either does “sensitive” work here?
Should log messages be Low or Slow? I’m thinking Slow? Can we use this as an example?
Per the proposed scheme, log messages should be Optional, because their delivery or non-delivery does not affect operation of the system. This is not to say that higher-priority log messages are prohibited, of course.
I would desist from commenting on the choice of words (best effort and such); someone who has a better command of English than I do should do that instead.
