TCP/IP is not very practical for hard RT system and of course useless, if there are physically unidirectional connections (no ACKs).
Modern plains use Ethernet as their network topology as in AFDX (Avionics Full-Duplex Switched Ethernet). Standard network switches can be used, but there are special chips in each node NIC that limits the percentage of total network bandwidth a node can use.
On Fri, 24 Jul 2015 18:24:27 +0300, snipped-for-privacy@downunder.com Gave us:
Does it reign mainly in those plains? :-)
I can't speak to avionics, but the radar systems of my experience use UDP/TCP (usually via ordinary ethernet), with application-level handshake protocols if reliable transport is needed (usually it is not).
Joe Gwinn
In radar, stale data is worse than no data. There is no sense in timeout
I did not say that I think it's possible. Read what I said.
AFDX was initially used on Airbus A380 (including fly by wire) and later on A350.
In industrial applications, often UDP, UDP multicast, Raw (MAC) unicast/broadcast Ethernet frames are used.
In a RT system, if the data doesn't arrive on time, the system is faulty and anyway, the late arriving data is useless and often harmful.
In such systems the Ethernet simply replaces the CAN/RS-485 networks with fast and cheap Ethernet hardware instead of expensive and/or slow special cards.
TCP/IP is particularly harmful, if some frames are lost. After some timeouts, the lost data is retransmitted, but at that stage hopelessly outdated and useless and also delaying the delivery of fresh data that might still be useful.
How is a programmer to know?
Would you use a semiconductor
As far as semiconductors go, about the only troubles we have with parts is things not mentioned (I suspect deliberately not mentioned) on data sheets. Like a chip going crazy when a small ESD diode current is injected, far below the abs max limit.
In a software package, you're lucky to find a clear statement of what the software does, who wrote it and when, or how to apply it. Software documentation is appalling. People are expected to read the seldom-commented source code, in max-obfuscated c, to figure it out.
They go together. A good single-programmer project can be both.
You can't test reliability or security into code, because you'll never be able to try all the cases. Like reliable hardware, they have to be designed in. Most software testing is done by the users.
The prevailing software culture is a disaster. It's not reliable, secure, or cost effective.
I think that a minority of programmers understand much math, much less
2s complement binary math. That keeps amazing me, every time I encounter it.Just wait until every door lock, every refrigerator, every traffic light has an IP address.
Wouldn't it be nice, but alas, no. Have a look at comp.risks for the whole sad story.
The reason for that is actually to get people to watch the safety demo. (This scuttlebutt is from my daughter the flight attendant.)
You'd think, in this day and age, wouldn't you. However, people are still pushing internet voting, which is an even bigger disaster.
Cheers
Phil Hobbs
If you are just "grabbing whatever you find available" (from past projects, FOSS, commercial offerings, etc.) you *don't*!
Do you buy your semiconductors from "whoever happens to have the cheapest, prettiest components?" Or, do you do business with firms that have a reputation on which you can rely (based on your past experiences, word of mouth, etc.)? There are offerings that actually make *claims* as to their robustness, suitability for particular applications, etc. But, you have to go looking for them.
[Recall, you can implement a piece of software (e.g., a library) in many different ways. So, looking for an implementation that optimizes the criteria that are important to *you* becomes the challenge]A firm I worked at many years ago tried to establish "Standard Product" for software components. The goal being that we could pull "modules" off the shelf and piece together a new system without having to redevelop each "component". The same applied to hardware modules. It's never 100% successful because there are always hardware and software differences between products/systems.
-----------^^^^^^^^^^^^^^^^^^^^
For most software components, *MOST* "things are not mentioned"!
Something as simple as a routine to multiply two values will probably be "documented" as: "returns the Product of Multiplier and Multiplicand" which, of course, is what it *does*. But, how fast it executes (on a particular processor or class of processors), how much internal "working memory" it requires, how much stack space, which *algorithm* it implements, whether or not it includes any optimizations for certain boundary cases (x 1, x 2, x 10, x 0, etc.), if it can overflow (and how that is handled), if one/both/neither arguments are signed (assuming *how* sign is represented is already known -- sign+magnitude vs. 2's complement), etc. are probably not mentioned *anywhere*!
And most users don't read the documentation that's available. This is particularly true of desktop applications.
[I've been reading user/owner/service manuals for new vehicles to help educate myself as to what to look for in those vehicles BEFORE taking a test drive and wasting time with an IGNORANT salesperson. How many folks have read the manuals for *their* vehicle? Even the *owner's* manual/guide?]Consider a piece of hardware (deliberately ignoring any software components) -- power supply, radar unit, etc. How much effort is required to document it's performance, limits, etc.? A modern CPU by contrast may have 1000+ pages just documenting *it's* internal hardware.
They *should* go together. But, some folks would tolerate a reliable program that is insecure while others would tolerate secure but unreliable. (we've not even discussed "correctness")
Most *desktop* software is tested by users. Because the belief is that it is easily upgradable. There are even development mindsets that effectively *encourage* this.
OTOH, most embedded software is inconvenient to upgrade and costly to upgrade. When was the last time you upgraded the software in your sewing machine? Microwave oven? Home audio system? TV?
[Things like cell phones blur this distinction]There is also an amusing dual standard when it comes to desktop software -- which is sold AS "software" vs. products that are
*essentially* software but regarded as "devices". In the former case, "no warranty, express or implied". In the latter, if the device "doesn't work" because of a software problem, it is considered (by the purchaser) to be *broken* -- and, invariably, accepted for a full refund. [IANAL so I can't comment on whether or not there is a legal distinction]Most folks writing software are "programmers". They have little (or very shallow) formal theory regarding "software" itself. They've been spoon-fed the latest programming language du jour. They have been taught to think they can just piece together apps in some does-it-all-for-you *framework* without consideration for what's happening (or NOT happening!) under the hood. They've been educated by a system driven by the businesses that want to hire them "tomorrow" and have "product" by Monday at 9AM!
As to "cost effective"... if the software they churn out ("hack together") gets to market quickly and brings in revenue for their employer, isn't that effective? Looking at the same issue from two different sides yields different assessments of the exact same situation!
E.g., most folks who have waited in line at the Post Office would consider it "terribly inefficient" -- they equate "efficiency" with the *shortness* of their wait; how quickly customers can be processed. From the USPS's point of view, having ONE clerk at the window is far more COST-efficient than having 2 (or 5!). I.e., as long as customers don't decide NOT TO MAIL THEIR PARCEL, there is no cost to the USPS for increasing the average wait time of the customer!
Most *people* don't understand "numbers", let alone "math". When I've been asked to tutor friends' young kids (in math), I invariably start out with a little game: "Show me '1'" "OK, now show me '10'" you can imagine how this would go with a young child :> "What about '100'?" (Hmmm... ran out of fingers! :> ) "And, '1000'??" etc. It's an interesting exercise that isn't very threatening. Yet, forces the child to imagine magnitudes and quantities. E.g., he may point to a (small) orange tree to signify '100' (presumably, regarding the hanging fruit thereon). And, then point to a small bucket of pebbles to signify '1000' -- "bigger" doesn't necessarily equate with "more".
As re: math packages, many who *use* them are ignorant of their common pitfalls in how they are applied. E.g., combining values of vastly different magnitudes -- and wondering why precision is lost; poorly ordering operations -- and wondering why overflow; etc.
[This was my motivation for implementing BigRationals; so Joe Casual User could write a piece of code that applies some arbitrary calculations WITHOUT REGARD FOR ORDER and be assured a *correct* answer, without fear of overflow, cancellation, etc.]IME, the software in embedded systems tends to be much more robust than on desktops. But, that doesn't mean they are secure.
E.g., when Google is offering you a service to remotely control your Nest thermostat, IP camera, etc. information is leaving your premises and traveling into *their* arms. Presumably, because they *need* that information. But, you now have lost control over it. What's to stop them from selling it -- perhaps not directly but allowing their customers (businesses) to bundle advertising to "folks who stay up late at night" or "folks who raid the refrigerator often" or...
Is that any better than them selling access to "folks with more than $500,000 in liquid assets"? Or, folks expecting a new child?
How do you define 'secure'? :> Secure from who/what??
My biggest criticism of Fords, but also VW's and others, is that the center console is so ridiculously wide it crowds your legs.
We ruled out most of the Subaru models for exactly this reason. The "inside leg" (i.e., left for passenger; right for driver) is pushed "out" too far -- does not remain in line with the corresponding *hip*.
Note that the console itself isn't that wide. Rather, it slowly tapers as it meets the floorboards -- *too* slowly! So, is probably
4-6 inches wider when it ultimately reaches the floorboards than it is nominally.We noted some of the Volvos had problems on the *outside* leg; as if they made the wheel well wrong -- protruding into the passenger compartment.
The Lincoln (?) had a power tap on the passenger side of the center console that interfered with passenger's inside leg.
Etc.
I guess they are used to "crash test dummies" that can't complain about how uncomfortable they are!! :-/
That, and they figure folks are more interested in the "tech" than the vehicle itself!
[Looking at a Nissan today and managed to crash the "nav/audio" system. Amusing to watch the salesperson try to "finesse" that situation. "And, what is it that *you* do for a living?" :> ]Have something to add? Share your thoughts — no account required.
Ask the community — no account required