On Wed, 10 Jun 2020 10:50:03 +0200, David Brown
<david.brown@hesbynett.no> wrote:
>On 09/06/2020 20:50, Joe Gwinn wrote:
>> On Tue, 9 Jun 2020 12:21:27 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>>> On 09/06/2020 01:16, Joe Gwinn wrote:
>>>> On Mon, 8 Jun 2020 21:44:50 +0200, David Brown
>>>> <david.brown@hesbynett.no> wrote:
>>>>
>>>>> On 08/06/2020 17:09, Joe Gwinn wrote:
>>>>>> On Mon, 8 Jun 2020 08:35:00 +0200, David Brown
>>>>>> <david.brown@hesbynett.no> wrote:
>>>>>>
>
>>>>
>>>> Lots of US DoD systems, largely but not exclusively radar, some quite
>>>> large. Some civilian weather and ATC radars. And the like. There
>>>> was always a radar somewhere.
>>>>
>>>
>>> Okay. This would seem to be a very specific field - one where you are
>>> using embedded systems that need a significant amount of processing
>>> power. It's the kind of thing where you want high processing speed
>>> using whatever technology is available and best (be it multiple cpus,
>>> FPGAs, DSPs, or whatever) - mostly regardless of size, power, cost and
>>> complexity. That makes it an outlier in the embedded world.
>>>
>>> If you say RHEL is used on these systems, I'll accept your word for that
>>> - you are the expert there. But if you were to look at these as a
>>> proportion of embedded systems that are made, they would not register on
>>> a parts-per-million scale.
>>
>> Well, the market leaders by units in the field will be whatever is
>> used in appliances like toaster ovens and microwaves - these are often
>> 8-bit processors running on the metal. Followed by smart phones (iOS
>> and Android, both are linux varients). Followed by automobiles (no
>> idea).
>
>You've missed a /lot/ in that list, but yes - the huge majority of
>embedded systems are not running a "big" OS like Linux. And that is
>even if you include phones and tablets as "embedded systems", which I
>don't think is appropriate.
>
>The vast majority of hard realtime systems do not use RHEL. The vast
>majority of RHEL systems are not hard realtime. There is, apparently, a
>niche where RHEL is used in hard realtime systems - though in fact the
>way you describe it, RHEL is not used in the realtime part.
Majority never claimed.
Depends on just how realtime it needs to be, as described later.
>>> (Smaller radar systems are becoming a lot more common, especially in the
>>> automotive industry. These systems don't run Linux on the radar
>>> detection part - though the "brains" of the driver assistant system
>>> probably does. But it won't be RHEL.)
>>
>> Those 77 GHz radars used in automobiles are components. Probably only
>> FPGAs or ASICs inside, but invisible from the outside.
>>
>
>The line between "component" and "embedded system" is as indistinct as
>other classifications we've been discussing. These systems will almost
>certainly have microcontrollers or processors (possibly inside an FPGA
>or ASIC, possibly outside), and I think it would be entirely reasonable
>to call them hard realtime embedded systems. Equally, it is entirely
>reasonable to consider them as black boxes used by other parts of the
>complete system. It's all a matter of viewpoint.
Yes.
>>>>>> A lot of standard RHEL is used, but of course options are chosen to
>>>>>> suit the matter at hand.
>>>>>>
>>>>>> VxWorks was also much used, but is fading, being replaced by RHEL.
>>>>>
>>>>> Again, I'd wonder what the use-case is. To me, VxWorks and RHEL cover
>>>>> very different kinds of system.
>>>>
>>>> In the old days, a common pattern was to have a Motorola SBC running a
>>>> RTOS (often VxWorks, but I've used many others) connected by a
>>>> communications link (bespoke in the old days, now usually ethernet) to
>>>> a main computer of some kind.
>>>>
>>>> The SBC had the hard(ish) realtime code that directly controlled the
>>>> radar hardware, implementing commands from the main computer and
>>>> reporting back.
>>>
>>> Sounds reasonable.
>>>
>>>>
>>>> The main computer was everything in the old days - I've used VAX/VMS,
>>>> Harris Nighthawk, Concurrent, SEL 32/55, and so on. Over the years,
>>>> UNIX displaced all these, but the platform was proprietary - SGI, IBM,
>>>> HP, Solaris, and so on. These have all been swept away by Linux on
>>>> X86 hardware.
>>>>
>>>
>>> What you are talking about here, assuming I understand you correctly, is
>>> the machine that is tasked with handling the data, doing calculations,
>>> and presenting it - not the part doing the realtime work (that's the SBC
>>> controlling the radar hardware).
>>
>> Well, "realtime" is not a binary property - it comes in degrees and
>> kinds of urgency, not just yes or no.
>
>That's also a matter of definition. Many people would say realtime /is/
>binary - either your system can guarantee to meet the deadlines, or it
>can't - and missing a deadline is a failure. (Controlled handling of
>failures is another issue altogether.) Others would say that only
>applies to "hard" realtime, and that you can have "soft" realtime where
>a few missed deadlines might be acceptable.
We had a lot of these kinds of debates in the 1970s and 1980s.
The physical world sets the required response times, so in the '70s
and '80s, computers were hard-pressed to keep up, so we did a lot of
assembly code running on bare metal., and used a lot of expedient
assemptions and ugly shortcuts.
But Moore's Law won over time. It has been 50 years since 1970. Over
that time, by Moore's Law, computer performance increased by a factor
of 11 billion.
But the physical world did not speed up, and it still sets the
required response times. So we now can do lots of things that were
unthinkable back then.
>> Here is a good example from phased-array radars:
>>
>> All otherwise unused radar timeline is spent sending search waveforms
>> out. This is a background, non-realtime operation. It only matters
>> that one gets enough search waveforms out onmoving-window average that
>> things cannot slip through the radar fences and escape detection.
>>
>> When a search waveform gets a hit, a realtime algorithm is triggered.
>> One must get a verify waveform out within say a few tenths of a
>> second, to ensure that the search hit was not a random blip, and to
>> get a more accurate target location in both alt-az angle and slant
>> range. Velocity is not yet known.
>>
>> If verified, a track initiate sequence commences, the purpose being to
>> determine the direction and speed of target motion before the target
>> gets too away for re-acquisition to be practical. So all this is
>> realtime, but a microsecond or even a millisecond here and there makes
>> no difference. This is dominated by the physics of target motion and
>> of radar, and not usually by computer issues.
>>
>> The resulting data is used to create a new track data structure, and
>> subsequent track maintenance requires only roughly periodic track
>> waveforms to refresh the track data. In the air traffic world, the
>> refesh is done every ten seconds or so, unless there is special
>> interest in a track. For precision approach, two seconds is common.
>
>All you are saying is that you have timing requirements that are
>different for different aspects of the system and in different
>circumstances.
Yep. We always did that, even in the days of assembly code running
directly on the metal, because we had to.
>If a failure to meet those timing requirements is considered a major
>fault and the system is not good enough for the job, then it is a hard
>realtime system. If you can accept a certain limited decree of failure
>on these timings, it is a soft realtime system.
We to were that absolete, back in the day.
>>>> In parallel, there would be a Signal Processor that originally was a
>>>> bespoke hardwired computer that implemented a single algorithm
>>>> extremely fast, turning raw I&Q data from the REceiver-eXciter into
>>>> detections, which were then passed on to the main computer, where such
>>>> things as tracking was implemented.
>>>>
>>>> Over time, the SP function migrated into purchased large computers,
>>>> and eventually became pools of enterprise-server class x86 boxes
>>>> running RHEL.
>>>>
>>>
>>> By this stage, you are not really talking about embedded systems. (The
>>> SBC running the radar is an embedded system.) You are talking about a
>>> server system - a compute farm. I don't think there is any clear
>>> definition of what an "embedded system" is, but I'm reasonably sure that
>>> a definition would not include banks of off-the-shelf x86 systems
>>> running an off-the-shelf server OS.
>>
>> Again, embedded does not mean small and really fast, although that's a
>> common combination. Nor does it depend on the number of processors or
>> cores employed.
>
>Agreed. But just because there is no fixed limitation here, does not
>mean you can't differentiate - it just gets hard in the grey area and
>boundaries.
The 1003.13 Rationale lays out how their definition arose. It's
almost a definition by exclusion.
>> There is an official definition:
>>
>> From IEEE Std 1003.13 (IEEE Standard for Information Technology�
>> Standardized Application Environment Profile (AEP)�POSIX� Realtime and
>> Embedded Application Support), also known as POSIX.13:
>>
>
>POSIX is relevant only for a /tiny/ proportion of embedded systems.
Yes and no. VxWorks is the market leader by dollars, but certainly not
by units. The current VxWorks conforms to POSIX.13, because Wind
River's DoD customers insisted on standards compliance.
But I'll grant that it at least used to be unlikely that the
microcontroller in a toaster oven had any OS at all, and these kinds
of applications were and still are where the big volume by units is to
be found.
>> "3.2.7 Embedded Computer System: A computer (and its software) is
>> considered embedded if it is an integral component of a larger system
>> and is used to control and/or directly monitor that system, using
>> special hardware devices."
>>
>> One item from the corresponding Rationale: "Is the internal
>> microprocessor controlling a disk drive an example of an embedded
>> system? Yes, regardless of what the disk drive is used for. The
>> software (firmware, actually) within the disk drive controls the HDA
>> (head disk assembly) hardware and is hard realtime as well."
>>
>> Special hardware devices are such things as radar hardware and rotary
>> cement kilns. Disks, displays, and printers are not special devices.
>>
>
>That "definition" is as arbitrary as any other.
Well, standards groups do make choices, and this definition was agreed
by a formal Ballot Group.
>>>> Neither does embedded mean small. Some of the radars I've worked on
>>>> are ten-story high buildings with 27-meter diameter antenna patches on
>>>> three sides. There were offices behind those antenna faces.
>>>
>>> I think we simply have a different meaning of the term "embedded". As I
>>> said earlier, I don't think there is a clear definition. But IMHO,
>>> these computers are not embedded systems.
>>
>> As discussed above, there is in fact a clear definition of embedded.
>
>It is not clear, and it doesn't apply to more than a tiny fraction of
>embedded systems. (I can't point to any better definition as an
>alternative.)
Well, the POSIX.13 definition is actually quite clear. You have a
different definition. What is it?
>> I'll grant that people did struggle with this, largely because
>> embedded systems come in a wide variety, so counter-examples abounded.
>> The earlier definition is what remained.
There is a Rationale, with all the counter-examples considered during
adoption. I'll publish the relevant Rationale text in a new thread.
Joe Gwinn