Posts by Electronics'R'Us 522 publicly visible posts • joined 13 Jul 2018
The right thing to do to prevent the internal corruption and machinations being made public (Although the majority of denizens here weren't fooled).
The really shady nature of the proposed 'buyer', hidden below lots of layers of obfuscation should (and did for many) set off alarm bells. Well done to El Reg for the in depth reporting.
This is far more likely to be an issue on the production line; there are many variables involved but it could be as simple as a chip shooter being misaligned (it only has to be a few degrees out) which can cause damage to the part that might not show up for quite a while.
I have seen that in the past.
It might also be an incorrect value (I have seen that on multiple occasions) that causes a cascade failure later.
The vast majority of parts used today are surface mount (no colour codes) and different manufacturers have different ways of encoding the value that does not match the classic method (1st significant digit, 2nd significant digit, multiplier) (argh) so it is not always clear just what the part really is. Sometimes there is a third significant digit.
There is little incentive to ship counterfeit resistors of the bog standard type (in large quantities such as Switchzilla would buy, they are literally dozens to a penny. These things come on reels of up to 10,000 parts).
There are occasions when the incoming product is defective; if that is true then the bill would probably go to the vendor.
Whatever it is, this sounds like a batch problem (either from the part or the actual line) as it is highly likely that Cisco uses multiple manufacturing locations for different pieces of kit.
The current high level synthesis tools supported by XIlinx are Vivado and Vitis which do indeed have support for C, C++ and System C.
The problem I have with trying to introduce this into C is that it encumbers the language with something that outside of hardware optimisation for FPGAs (and ASICs) is not going to be useful and simply muddies the waters.
When writing Verilog or VHDL we state the size of the fields required explicitly anyway; the problem arises when using high level syntax (in whatever language) in a HDL environment (with the inherent specifics of what data types are available) for something that was never originally intended by the language.
There could be an extension for the FPGA tools where the necessary size could be stated; there is nothing stopping the FPGA tool vendors from adding such an extension (they would need to advertise it as C / C++ / SystemC / <insert your favourite language here> with hardware extensions).
I understand why we use high level synthesis (take a look at the OpenSparc verilog source if you want to see how complex, and therefore bug prone, a large project can be) and on today's monsters such an approach is necessary.
This does not, however, justify adding this formally to C (my view, obviously).
Indeed; the impulse response test had significant harmonics out to at least the 7th and I found that a couple of pulses of different durations (and therefore differing frequency content) increased the accuracy of the test.
NiCd batteries are far more difficult to analyse than Li+ which do have a reasonable relationship of terminal voltage to state of charge; The open circuit and loaded voltage of NiCd tells virtually nothing about the state of charge of the cell.
What I did find was that by loading the cell with a pulse and measuring the complex recovery curve (RLC) relative to the unloaded voltage I could determine the state of charge which was accurate and even accounted for memory effect (where an apparently fully charged battery may be able to provide much less than the nominal full charge).
So hardly a new idea; the company I was at did file disclosure to the USPTO (I was in the USA at the time) so it should stand as reasonable prior art.
The up front analysis took many forms before I found one that appeared to correlate (pulse testing); what is interesting is that the entire analysis was done with a precision discharge circuit (I already had that available), a charging setup, a multimeter, a cheap oscilloscope, a few resistors and a timer (and a lot paper and simple mathematical analysis).
Oh - you are right; and a lot of thought.
Having once spent a year (at least it felt that way) analysing the charge state of NiCd batteries, I can say that impulse response (a form of ac excitation which does indeed measure the impedance) is a pretty accurate measurement method for rechargeable batteries.
The problem is that battery construction (there are a lot of ways to construct a battery in a given technology depending on the end use) requires each type of construction to have its own training data which I had to do by hand (this was 30 years ago and I tested literally thousands of batteries from multiple manufacturers and batches) although the 'typical' construction for a given battery yielded type consistent results across manufacturers (the manufacturers said it was impossible to know the charge state but they would - they were in the business of selling new batteries).
There are a lot of gotchas in this field but with sufficient training data the analysis can be quite accurate.
I ended up building an analyser with a microcontroller and the results were tested by actually discharging the battery and confirming that the test had reported the correct charge state - it was always within 5% of the reported state of charge and typically within 2% so it is possible.
Works great.
Wherever there is a facebook button, it overlays a little gate icon to show it has detected (and blocked) the slurper.
Never had a farcebook account and never will. Ergo, they should not be able to track me around the web and this nice little tool does precisely that.
(I have also disabled flash 'cookies' without going to the website and asking for it - it is really simple).
This is certainly an area of active research (and has been for some time).
There are a number of sides to automation.
1 Increased reliance on the automation over time (because it works most of the time) which leads to slower reaction times when a situation it cannot handle appears. There is a reason that aircraft simulator time with nasty failures thrown in is pretty standard - to ensure that if a bad situation does happen, the aircrew still know how to deal with it. If we are going to have auto-pilot equipped vehicles we need to mandate regular training because otherwise drivers will eventually forget what to do (at least, do it quickly enough to avoid a nasty situation). That includes a nasty electric shock to the operator who decides to play a game on their smartphone.
2 Redundancy (sensors, compute elements). Avionics is a reasonable area for automation for a variety of reasons provided the sensors are all operational. Even if a given sensor is not operational, triplex designs can handle that by voting. The compute elements must also be galvanically isolated so that if a compute device fails hard, it cannot drag down the other computing boxes.
In the case of vehicles, the number and number of types of sensors needs to be addressed. Cameras are great in some situations but not in others. Likewise Lidar and mm wave Radar. There needs to be a way to use the best sensors at any given time but I have yet to come across serious research into that subject (if you know of any, point me at it).
The entire design needs to be assessed with a proper FMECA so that no single failure can affect the safe operation of the system or at least require the operator to take control (see training above).
All this adds significant cost to the solution.
3 Conditions. Road conditions (road type, visibility, weather, traffic density) have a huge influence on the effectiveness of any automation (and more than in aviation where things are fairly stable). This means that scenarios that are relatively rare in aviation (especially since we got ADS-B) such as a sudden stop in front of you must be considered (there are a lot of these - this is just one example).
Without a mandated safety standard and a requirement to actually implement it, auto-pilots should not be trusted but people will continue to use it in such a way that is not really safe.
As always with technology, there are trade-offs to be considered (every system design is a compromise).
...that the software makes decisions - Dick says a human copper always makes the final decision
This is sophistry of the worst kind; of course the software makes a decision by flagging a (probably completely innocent) passer by who will then have their collar felt by the plod (because the computer said so - does anyone actually believe the plod won't do that because you know terrorism, kids).
Then we get this gem:
...and that the Met is being secretive about the technology - Dick says the Met has been “completely open and transparent about it.”
Absolute excrement of male bovine - it took a FOI request to get any real information on these so-called trials.
She is just a politician (the met has been that way for a long time) who should be fired; I would prefer a real police officer to be the commissioner.
Here in Cornwall, there are many lanes that are single track with the occasional passing zone although those are little use if someone is approaching in their tractor (this is farm country) or an oil tanker (lots of oil fired heating around here). In those cases reversing to a relatively wide part of the lane is required.
I live along one of those lanes and there are a lot of blind bends and some of the people driving on them seem to think they can do the national speed limit even at those bends; I compensate for that by approaching said blind bends at a safe speed (you need to be able to stop in the distance you can see).
Amusingly, the forward facing cameras in the vehicle detect speed limit signs and the onboard computer duly displays it on the map and in the instrument cluster (the map can be used as a satnav although I don't), but when it encounters the national speed limit sign on the entrance to a lane, the computer gets confused and just displays 3 dashes (because it gets confused by a mixture of national speed limit sign and a single track lane).
The point is (as noted by others) that the speed limit is a limit, not a target. On the open road in good conditions I usually do the speed limit, although even that is not really too safe depending on what is being driven on the rally driver slalom training course otherwise known as the A38 in southeast Cornwall.
Let us not forget that Apple was one of the gang of four that made a settlement for their illegal no poaching pact.
Now they are trying the same thing on with these guys; I have no doubt that any Apple ex-staffers that went to the new outfit did so because it would be really cool stuff to do and it is likely (knowing designers) that they applied rather than being poached deliberately.
There is at least one vendor of Electronics EDA that used (and still uses) Delphi for their tools. Apart from the user interface parts, these tools are, in reality, very complex databases and need to be managed as such.
Some other tools use the ODBC route (so you use the database of your choice and simply tell the system which one it is).
I used Borland Pascal back in the day, then Delphi. I was quite taken with C++ Builder (which brought the visual form builder to the C++ development environment) and wrote many a program with it although it certainly had it's quirks (particularly with callback naming conventions) but it was still a major step for the time.
Given that in the USA (at least) applicants to be plods can be rejected for doing too well on a test, I am not that surprised.
I started out doing machine code and assembly (it simply doesn't get lower level than that) and I would expect this lot to consider someone who understands the internal operation of microprocessors in great detail to be a threat to be reported.
So if the kids have microcontroller starter kits (great for learning about the internals) are they to be reported as well?
I sense an ID ten T error here.
I also share your despair over completely uneducated idiots trying to make themselves look as if they actually know something; in this case they have just shown the world just how stupid they really are.
John Gilmore said in 1993 The Net interprets censorship as damage and routes around it.
Just how they think this can be enforced is beyond me.
I think they need to send this one along with the you must give us your encrypted communications but it won't be used by the bad guys to the newly created Ministry of Magical Thinking (at least then the name would be accurate).
The issue here seems to definitely be from management but the real problem is that their attitude filters down to just about everyone.
I have seen issues where a ships company (Royal Navy) was so toxic that the entire crew were re-assigned elsewhere (and all on the same day) with an entire new crew brought in. In that case, the more senior officers were also re-assigned to desk jobs or quietly convinced to resign / retire.
The same has happened to army regiments in the past. Once the rot sets in, it affects everyone.
In this case it appears the bean counting attitude has filtered down to lower management (so the rot is just about complete) and the best solution would be to completely replace all of them (which sadly won't happen).
I have worked with safety critical kit, and we would never skip a design review (where you have to show just how you have actually met the system requirements); this tells me that Boeing apparently thinks that system requirements and formal validation are unnecessary - this is total madness. If we were late on the programme, we were late and we would tell the customer and explain how we were going to recover.
Skimping on proper engineering (not just software - if this is happening there, it is happening in all engineering disciplines) is a recipe for disaster and that is where it has taken Boeing in more than one area of the company with only a token CEO 'leaving'; this attitude needs to be ripped out entirely.
Many years ago I was an expert witness in a patent infringement claim in the USA; each side can have as many expert witnesses as they want and in a civil case they are deposed by the opposing counsel.
In a civil case in the USA, virtually all the answers are known prior to the case ever getting near a courtroom due to disclosure - one attorney I know told me that none of the lawyers would ask a question where they did not already know what the answer would be. He also told me that in technical cases, the most believable expert would carry the case.
Two (or more) subject matter experts can differ on things (one thing I had to explain was that a battery and a capacitor are not the same thing at least in that particular application).
In the end the plaintiff gave up.
The company hasn't been BAe since 1999 when it merged (bought out in reality) Marconi, after which it was re-branded BAE Systems (yes, I used to work there).
The two overarching setups are BAE Systems PLC (UK) and BAE Systems Inc (USA); one of the UK sites is part of Inc which makes for an interesting time from a security standpoint.
Within those, there are numerous business groups, some better than others.
In the (rather distant) past, I had a girlfriend who was a practicing lawyer in the criminal courts for both state and federal and I was told I would never be an active member of a jury simply because I have a degree level education.
Well educated? Off you go.
The reason is that there are a number of pre-emptions permitted (so the lawyers can get rid of a juror for virtually any reason at all).
He may also not get a jury at all and have just a federal judge deciding his fate.
The right to trial by jury for serious offences is a constitutional right so there will be a jury trial; it is in the lawyers interests (on both sides although in this case I would love to see tech pros but I won't hold my breath) that those jurors are not particularly well educated.
One place I worked at was the provider of the head up display for an american fighter; after some time of being in service, we were getting returns where the fault was listed as 'shutdown due to overheating'.
So the repair crew duly ran them through their paces and could find nothing wrong at all - all functionality fine, temperatures all well within normal limits - so they were shipped back.
We then had some more come in with the same reported problem yet we could find nothing wrong.
It turned out that the overheating was due to dirt and other materials found in fighter cockpits getting into the cooling fans, but the workshop crew packing them up first used some low pressure air to clear out the dirt on the fans (which was the actual problem as the dirt was clogging the fans until they could no longer function). No wonder we could find nothing wrong.
A little remedial training for the line / workshop crew and we did not see that problem again.
Dry Tantalum capacitors can be satisfyingly pyrotechnic even when installed in the correct way. When they go through reflow, it can damage the dielectric (particularly for larger parts in case size C and bigger) which leaves a small short circuit in the device - if it is powered up from a low impedance source (such as a power supply), that short circuit becomes literally white hot and leads to thermal runaway.
That is known quite charmingly as an ignition failure and tends to leave a device where the solder terminals and outer case (sans middle area) are present along with a grey blob from what was the internal tantalum
Had that happen quite a few times in a new flight control computer (I won't say for what aircraft).
Wet tantalums are also pretty renowned for their rather impressive failure mode; there is a 'self-healing' mechanism within the device that is not so much self healing as building up a future failure as the device ends up with a lot of free hydrogen internally and the internal pressure builds up slowly over time to the point the internal tantalum cathode slug is forcefully ejected by a very hot internal event. (The internal construction includes dilute sulphuric acid.)
These have nickel leads spot welded to the terminals; one failure had vapourised the nickel - considering that nickel melts (let alone vapourise) at around 1500C it is not surprising that the internal wall of the aluminium box it was in when it failed had significant scorch marks.
There are a few things out there, although not at the highest of speeds of current DDR4; for many applications, though, that speed is not really necessary (especially in the embedded space).
Everspin has a couple of devices with reasonable capacities but they are quite expensive compared to standard products; the advantage is that they survive power dropouts (very common in many applications such as avionics) and the application can reside within the devices.
They are also touting the parts for data centres.
DRAM is fast but volatile, meaning it loses information when its power source is cut
<pedant>
Well, that is true, but it also loses information in < 1/10 second if not refreshed (i.e. recharge the memory cells because they are a transistor used as a very small capacitor). The typical amount of time for a complete refresh (all memory cells get a recharge) is 64 milliseconds for current devices from DDR1 to the latest versions.
This is an overhead in all DRAM implementations (although it is transparent to userland but not to those writing the initialisation code which is quite interesting if you are using ICs and not SODIMMs).
The implementation of refresh circuitry is now well understood, but it still requires a lot of extra circuitry within the memory controller as well as the memory device and some power to operate as does the transaction based burst nature of all DRAMs (which makes them unsuitable for many applications).
SRAM (static RAM) also loses it's information if power is cut but does not need refresh; the penalty is more power required but they are very popular in some applications including some server applications.
Both the above are volatile types of memory.
NVRAM that runs at the same speed as standard SDRAM (DDR3/4 and so on) is available but they are a bit expensive but there are advantages such as very fast boot times as the OS (if used) does not need to be loaded from one memory (typically flash) to main DRAM.
</pedant>
I have lost count of the number of times I have been told that processing cycles and memory are cheap, so bloat is perfectly acceptable.
I would like to see them try their hand at deep embedded where those things are not cheap because there isn't enough space to put a lot of memory and a very fast processor (because you can't get the heat out).
Sure, UIs can take up a fair amount of memory but the amount the current ones take is ridiculous (I can hear them writing it..."Oooo! Shiny!") and a simpler interface might well be better anyway (and use fewer resources).
Icon for the processing required.
Electron appears to be a problem in search of a solution (yes, I know which way round I put those :)
As Mark Twain wrote "There are lies, damned lies and statistics"
I agree with your scepticism of the apparently stunning advance in the recognition capabilities (read: we pulled this number from our propaganda files so I would add a 'citation needed' tag on that).
Facial recognition also struggles a bit with sunglasses (I wear photochromatic glasses and even in winter there is sufficient UV to make them go dark) and beards (which I also have).
Until the plod become technology literate (I won't hold my breath on that) they will not understand the limitations of the technology; all they see is a shiny new toy that removes the need for proper policing.
Slightly related.
In the 1970s, a UK university ran a study of the effect of calculators so it was a technology study in that sense.
They enticed people in with a couple of quid and were then sent to one of two rooms with desks, a question paper and calculators.
In one room, the calculators operated normally; in the other they were rigged to give ridiculous incorrect answers - think 7 x 11 giving a result in millions - over 70% of the answers from the group with rigged calculators ticked the clearly incorrect answers.
I would expect the plod to blindly accept the (incorrect) results and cuff someone because 'the computer says so'.
Idiots.
Anyone who has followed the H1-B fiasco is all too aware that people are being brought in from abroad to supplant more expensive local staff which is not the (written at least) basis of the visa program itself.
Nothing in this stops an outsourcer having staff that work at a client site; what this does stop is an outsourcer deliberately bringing in people on a non-immigrant basis who will not be working at the site of the sponsoring company. That does, of course, mean they would have to employ US citizens or legal immigrants for those roles, and they are denied the use of indentured servitude an effectively captive workforce.
At one place I worked there was an Indian on one of the various 'work' visas (very probably H1) and she was desperately trying to find a new sponsor so she could change jobs. The rule then (and probably still is) was that you could only work for a sponsoring company - if you left that job and no other company took up the sponsorship, the visa was void so back where you came from was the effect.
I seem to recall that once you had a number of years full time employment, you could apply for legal immigrant status.
These outsourcers use the sponsorship rule to effectively profit from the misery of others as they have no effective freedom to change jobs and therefore have no ability to walk away (unless they leave the country, although there are some very nasty tales of the outsourcers demanding money from these people if they ever do leave that way).
Whatever the reason(s), this rule update is actually a bit refreshing in that it clamps down on one of the worst loopholes in the H1 scheme.
Disclaimer: I lived and worked in the USA for 22 years (as a legal immigrant, not on a work visa) and saw some of the effective carnage caused by the cut price outsourcers.
Apparently then, from your description, it is the new version of General Farm.
The irony, of course, is that open computing has produced the most fevered upsurge in new technology since the Industrial Revolution.
When I was using a Netware LAN (that rather date it!) I was asked to come up with a way to determine what logical disks were local and which were on a network drive by the primary applications team (I was known as a programmer with an emphasis on low level structures and hardware).
That feature was part of the Undocumented internals of DOS. That book (and articles from numerous magazines of the day) helped me enormously as it documented the List of Lists (a veritable treasure trove of internal information) where the type of storage (local or remote) could be determined, among other things.
If what Oracle wants is granted, that book might never have been published (and many useful programs would never have been written).
It was the determination of those who wanted to understand the entire system (and therefore could control it in ways Microsoft did not want) that opened up programming in a way that enabled huge amounts of application software to be developed effectively.
Many moons ago in the early 90s I was doing code and hardware development for smart payphones (basically a microcontroller with support hardware that appeared to the user as a payphone (they were very popular in the USA at the time).
We were asked to do support for a different vendor (who had no engineering presence in the USA). One fine day some of these arrived at the company for repair.
The code (68HC02 as I recall) calculated the amount of money to be deposited for a particular call, but with some entries the result was clearly wrong (it couldn't even display it properly - it appeared the unit had gone completely wacky).
I extracted the contents of the EPROM (UV type) and armed with only a linker map went in search of the calculations using my (purloined) copy of Norton Utilities and I found a division routine that was possibly the worst piece of code I had seen up to that time and whoever had written the multiply and divide code had clearly never heard of underflow or overflow testing or even 'add and shift' or 'test, subtract and shift' which apart from being somewhat elegant have the advantage that the runtime is relatively data independent.
Once I figured that out, I got the instruction set mnemonics and codes from the datasheet and hand assembled replacements for said routines which were (thankfully!) shorter than the originals, then edited the hex file with the new routines (unused locations were padded with NOPs), burned new EPROMS and then everything worked properly - took me about 4 days IIRC.
I was asked if I could edit the background 'music' data to play something different but the quote we gave them for that meant I did not get lumbered with that.
Icon for the original coders.
I suspect there will have been quite a bit of surgery in the electronics as well.
The original kludge system was simplex (a single computer and a single sensor active at any one time); now that these must communicate with each other means that there is new wiring to actually implement a bidirectional channel which will also (of necessity) be galvanically isolated.
There are a number of reasons for this; the main one is to prevent a fault (a short perhaps) on one side from bringing down the other side and another reason is that the ground potential within each box is highly likely to be different as avionics never connects their internal ground directly to chassis (airframe earth) and the internal power is always isolated from the power source.
So we will then have (at a minimum) new wiring (and therefore new harnesses - adding wires to a bundle is not simple), new circuitry (to both electrically isolate the channels and to add this functionality as it was not previously implemented or if it was would not have been thoroughly tested as it was beyond the scope of the requirements). All this is quite separate from the necessary software changes to actually implement all this (and that alone will be huge).
This work would have been carried out (for the boxes at least) at the manufacturer (one of the usual suspects no doubt - Boeing does not make their own avionics) with a new set of cable harnesses; if that harness is not identical to the new ones in the Boeing test rigs and aircraft things are highly likely to break as software needs to be written to take these things into account (and it is possible that this functionality is within an FPGA - that brings up an interesting possibility of 1,000s of manhours to qualify it).
The aircraft level software is done by Boeing (or its cheap subcontractors) but the software within the box that runs the internal hardware is done by the box manufacturer; the integration rigs are used to verify everything, but a sample of only a few will not necessarily prove everything - for that you need production hardware.
The communications is quite possibly ARINC 429 (designed specifically for avionics) which is notoriously difficult to get right without significant iterations - once it is right it is incredibly robust.
Keep in mind that the change to the internal software is about more than just the communications; there is also the decision process (are both boxes agreeing is just one part of that) so this update is enormous.
In 1970 the UK military introduced a new set of paperwork that supplemented the original aircraft servicing books.
This actually made sense because in the section for problems (unserviceable, to use the proper term), the size of the corresponding 'here is what we did to fix this' writing area (yes, we actually used pens!) was large enough for about 3 lines of small text; hardly sufficient for the newer (and therefore more complex) aircraft and associated systems.
Some items did not require this new paperwork (an aircraft was declared unserviceable if the toolbox associated with it was checked out and the only response necessary was that the toolbox and all its tools had been checked back in - there were many such types of entry *)
All this was eventually sent off (the forms were multi-page - one page for aircraft records, one page for stores, one page for analysis and so on) to a RAF base in East Anglia where it was manually put into a large and power hungry mainframe to crunch all that information.
Some reasonable usage and spares predictions did indeed flow out of this (although it took a few years for those to become both available and reasonably accurate).
While inefficient, it was somewhat better than what had been done before, but it used up a lot of manhours and doing this properly should (in theory) be a massive time saver (I know - in theory - we are dealing with JPO - the JSF project office - and LM here).
One of the problems now that did not exist in those times is that most failed equipment could be fixed locally in one of the various workshops which is not a viable option today for a lot of reasons; being able to repair equipment on the same base meant that there was usually a stock of spare operational kit available. The concept of having a reasonable prediction of what and how many spares should be on hand is quite reasonable.
Many failed units today are sent back to the manufacturer(s) for repair and the turnaround times can be quite long. (I am not going into the reasons for this as books could - and probably have - been written on this subject).
One type of response is a key item to track - 'No Fault Found' - this costs a lot of time and money and if only those could be resolved it would save a lot of money; the problem here is that the system is trying to be everything to everybody and failing spectacularly at just about everything.
So the concept is great; the execution - well, not so much.
* Everything that was done to an aircraft was (well, was supposed to be - there were some exceptions that got people into quite a lot of trouble) recorded to the point there was a poster on the wall that featured a small child sitting on a potty (I know - that would not be politically correct in these days) with the caption "The job's not finished until the paperwork is done".
The new leadership team – from my director down – they all came from St. Louis, Missouri. They said they were all buddies there
The St. Louis site is from McDonnell Douglas (a primarily military site); clearly the effective takeover of Boeing by McDonnell Douglas at the executive and senior management level extended far beyond the (relocated) head office in Chicago.
I sense a shareholder lawsuit in the making here; he presided over a total failure to introduce a safe updated 737, a massive drop in delivered aircraft, a massive drop in orders (thus making the long term share price lower) and a significant drop in current stock price.
In the USA (in particular) I have seen shareholder lawsuits for less than that.
This will not be a simple matter.
Without MCAS (or a system that effectively does that function), the aircraft cannot pass part 25 of FAA regulations (transport aircraft) because the nose can pitch up more than the commanded (yoke) input without it.
They could:
A. Use both AoA sensors and both electronics units and if a disagree occurred (not an uncommon issue apparently for the AoA sensors on the 737) then MCAS gets out of the way and a cockpit alert is issued.
This would require a massive amount of total simulator time (once they actually get the simulator to properly recreate the actual aircraft handling) apart from other training. It will also incur quite a significant cost for the electronics and software involved (although that is a one time cost).
I am not sure the regulators outside the USA would permit a duplex system that disengages at a critical phase of flight (by definition, it only engages when it 'thinks' the aircraft is about to enter a dangerous phase of the flight envelope), but it would be a potential method.
B. Add a third AoA sensor (and pitot tubes apart from a great deal else) and a properly designed triplex computing system for a properly redundant triplex system.
This would require a complete rethink and re-statement of the system requirements and might be achievable in a couple of years (not including flight testing) but re-casting the system to level A (which it should have been anyway) will incur a great deal of testing and review (at the hardware, software, mechanical and system level).
Either option would require pilot training and re-certification which would not be a 'standard' 737 certification which means the airlines would not be able to schedule any '737' pilot to any aircraft. That would put the airlines off (they were the ones, after all, who were demanding 'just another 737, but more fuel efficient', without pilot re-training costs and simulator time).
Either option makes this a 'new' aircraft, in my view (others may differ).
I cannot see how this problem could be addressed without doing one of these (apart, of course, from just scrapping the programme in it's entirety which includes, lest we forget, the 737-8, 737-9 and 737-10).
I also cannot see it while the bean counters are in charge although they should be crying about all the beans they did not get to count this time.
The FAA might approve the design, but a complete re-certification from the other regulators around the world is likely to take years anyway.
In among those messages, seen by The Register, are multiple specific references to a 737 Max simulator installed at London Gatwick Airport. Boeing staffers appeared concerned that the sim wasn't going to meet its Level D certification (the highest level, necessary for the most demanding pilot training) because it wasn’t realistic enough.
In my experience, level D is one grade up from garage-ware (certainly in the DO-178 definitions); the most demanding is level A (failure is catastrophic).
Interestingly, ISTR that MCAS was originally classified as level D (I do not think any level above that would permit a single sensor and single processor for something that can operate flying control surfaces).
Evolving a design is usually better than starting from scratch (Agile verses Waterfall).
Sometimes; in a safety critical system, any single change requires a complete re-evaluation of the FMECA when done properly. That may show everything is OK, but quite possibly it will not. A single line of code change to DO-178B/C certified code requires extensive testing to ensure that the bug / feature intended to be dealt with has indeed done that, and nothing else at all in the code is affected. Hardware changes likewise as that can easily affect software and the system level impact needs to be evaluated.
All those old parts have proven infield use and safety.
Within the context of where they were previously used, yes. Outside of that context the answer is a resounding NO without a full evaluation within the new context.
You can iterate changes to lower the cost of manufacture and fitting of each component while maintaining safety
Which means you have to iterate the verification testing and analysis to show that the change has introduced the feature you intended and has not affected anything else
You can test each change
Not on actual flight operations until several 100s of hours (at least) have been run in the test rigs and even then it is a test pilot who has to fly the aircraft as an experimental flight sequence.
The problem is not so much that Boeing did all the testing, but that Boeing did not do adequate testing and also did not properly classify MCAS as safety critical. The reason is clear to me; time to market in the face of new competition and therefore profits and share price. The (criminally liable) ability to tell the airlines that previously certified 737 pilots could do just an hour of non-simulator time was (to Boeing and the airlines) an added bonus.
To call the compensation to the families of the victims of these decisions blood money is not an exaggeration in any way.
In its original definition, MCAS was not supposed to have full authority over the horizontal stabiliser but when that proved to not solve the problem (whereby it would not pass Part 25 - passenger transport aircraft - regulations) it got more than just a bit of design creep to the point where the system had full authority over the horizontal stabiliser, which the elevators, under pilot control, could not overcome even if they were at their full travel.
When it got to this point, an updated FMECA (which was probably never done) would have shown conclusively that MCAS would have to be treated as safety critical.
Here is where regulatory capture rears it's very ugly head; the bean counters would have looked at the time and money required to certify the system as safety critical and told the engineering staff to shut up and pushed the DER to make sure it was not so classified in any document not merely to the FAA but also to all the other certification agencies around the world if they had asked - it is for this reason that none of those authorities is likely to trust anything from the FAA (or Boeing) for a very long time.
I have commented before that surely the engineers involved (and not just at Boeing - the electronics behind MCAS was almost certainly designed by a third party) would have serious questions about the effects of the decisions being made by bean counters and not engineers.
Having designed and verified safety critical avionics I can state that it is a time consuming and somewhat expensive process when done properly but it is also necessary; when something fails in verification testing, it gets fixed - no ifs, ands or buts. There are times when an analysis shows it may not be necessary to do a direct fix, but that full analysis needs to be done and documented. This clearly did not happen in the case of the 737MAX (and very possibly on 787 and newer 777 products).
That is where the tone of these messages make sense; the engineers did not want to shut up (although they did as far as the public and the FAA were concerned) and although I can sympathise with them to a certain extent, the only decent thing would seem to be to quit and go public but with the sure knowledge that Boeing, with all it's money and political connections, would be looking for blood and to completely discredit any such individual (as, most likely, would the FAA).
If those people did not have the wherewithal to withstand such an assault (there are numerous documented cases of whistle blowers being hounded, sometimes to the point of suicide), then it is difficult to blame them (where the blame really lies is in the laws that fail to protect legitimate whistle blowers - i.e. politicians who receive bribes campaign contributions from mega-corporations such as Boeing)
I personally would not trust a Boeing aircraft designed after the original 777 to actually be safe by design.
I don't fly much (if at all) now, but SWMBO does, and I carefully scrutinise what aircraft are scheduled for the routes she will be flying; a little bit of hassle, but at least I know the aircraft was properly designed and all the equipment within it properly classified and designed and tested to that classification.
I also use NoScript along with the facebook container. I like the container - it refuses to let the 'like' buttons capture anything as I am not on their site (and I do not have a fb account anyway).
I have a paid subscription to a well known national newspaper and the only domain I permit for scripting is their own.
I do use Chrome on occasion (for those times when the site operator doesn't clearly state what other domains may need scripts enabled - in the UK a lot of them are like that, particularly gov domains) and if I load said newspaper site in Chrome, it maxes out a logical core on my laptop (7th gen i7) and takes a long time to load. When I look at the NoScript information panel, there are 2 pages of blocked domains.
Yes, for casual browsing I use FF with NoScript for El Reg as well. When I permit scripting I see lots of ads for Analog Devices (hint to El Reg - there is no need for that).
Faster loading, less tracking - what's not to like?
I solved the issue with flash locally stored objects long ago without having to ask nicely to not have flash objects locally stored - it involves removing a directory and making a file of the same name and then making that read only; no performance issues I can see.
Doing a regular clean of cookies is also wonderful (lets me view more than the 'permitted' number of articles from given news sources per month).
Well said.
I do not deny the climate is changing and nor does anyone I know; what is disputed are the various contributions to it. There are myriad potential causes (that interact, undoubtedly - perhaps some of those who claim 'the science is settled' should learn about chaos theory).
There are many anomalies in the data, and the paucity of the data (when trying to analyse a system as large as the planet) does not help. Most of the loud noises I hear are from those with a financial interest in it being believed - <sarcasm>who would have thought it?</sarcasm>
El Reg takes the view that 'pronouncements from on high' should often be taken with a very large helping of salt and looked at with a sceptical eye; show us the data and we will decide for ourselves about the accuracy of it, basically.
In the early 90s, I got a call from a 'colleague' who was having trouble finding a file he had created from a BASIC (I know, I know) programme (by using the dir command).
DOS (as it was) would not recognise filenames with spaces in them but it was easy to actually create a file with spaces in it from BASIC (a particular weirdness of DOS) to which one could happily write and read data from within such a programme.
I brought over my (invaluable) copy of Norton Utilities and used the file examiner (I do not recall the specific name), found the file and removed the space from the filename and all was well (the file now showed up in a dir listing).
I had hoped that he might have got the picture after I explained that filenames with spaces would not show up in a listing but the same thing happened a couple of weeks later; I could see the file with Norton but I did not change it and told him 'we must have been lucky last time' which did actually penetrate into his what passed for a brain as it didn't happen again (as far as I know).
You are correct, but a key cost cutting measure was to not classify MCAS as DAL A (failure is catastrophic) which meant:
1. Many thousands of manhours were saved in the process because DAL A designs can incur a paperwork overhead of about 5,000 hours before the first piece of code is ever written or the first schematic is drawn.
2. Lower standards of testing are required.
3. Lower standards of redundancy are required.
I have stated before that whether to classify a system or subsystem as safety critical (DAL A) is really not that difficult and in this case I cannot believe that the engineers(*) did not protest at MCAS not being so classified.
* This is not limited to Boeing; the actual computing elements were designed by a third party (the norm in avionics) who would have been given a specification of what it has to do (from Boeing who are the ultimate authority) and as soon as they saw something to the effect of 'can move / adjust the position of flying control surfaces' (the specifics are part of what is known as control laws) I have no doubt that there would have been questions. The paper (or documents and email) trail of those conversations would be very interesting reading indeed.
Would the doctor have us rename a popular quiz show? What would it have to be named, one wonders. The entire point of the name is that the resident team are rather like walking encyclopedias! If that is not a compliment, then what is?
As to words hurting - I can see that for a youngster, although when that stuff (I particularly remember swot and bookworm) was spouted at me in my youth (many years ago) I was told by my family (who were very working class as it happens) to simply ignore it as jealousy, which indeed it was. I was encouraged to always be better at what I enjoyed (the usual geeky subjects but also things such as geography, cartography and technical drawing).
I never had the desire to be a part of the various cliques who appeared to celebrate idiocy and were indeed bullies, but I found that telling them they were not worth my time and trouble deflated them. Notably, many of them came from higher income backgrounds and were no doubt practicing to become slave drivers managers in later life
I have had various titles such as Electronics Guru, Diagnostics Wizard and PCB Design God which I took as compliments as they came from other engineers. I remember interviewing for a job where the description was Must be able to fix anything in hardware and software. There were others but I am sure you get the drift.
I even had one engineering director saying they needed to hire another me which is perhaps the highest compliment I have ever had considering the knowledge level of the rest of the staff.
I have had the words geek and nerd thrown at me online and I would simply say "Thank You!" which rather seemed to put the trolls off their stride a bit.
I must admit that a difficult childhood (and I was a difficult child as well) and almost 12 years in the armed forces rather thickens the skin, to say nothing of design reviews (where wearing the equivalent of asbestos underwear might sometimes be recommended).
We certainly don't need a trick cyclist to tell us what is a compliment and what is intended as an insult (which is an insult to our intelligence in the first place, ironically).
Agreed, but there is something even more fundamental; the aircraft cannot be certified as airworthy under part 25 of the FAA airworthiness regulations without some system that prevents an increasing rate of angle of attack for a constant pressure on the controls.
In certain phases of the flight envelope, the angle of attack rate can increase uncommanded (which can indeed induce a very nasty stall situation and is all due to the size and placement of the new larger engines); that is the primary reason MCAS is present (quite apart from any other consideration).
.
This sort of thing has happened many times (particularly in the USA where total taxes on various items can vary even across towns and cities within a state).
A couple I can think of:
Back in the 90s the price of tobacco products in Michigan (and in particular in Detroit) rose dramatically; the only problem here is that Canada is but a short drive away so the locals would take a day trip once a week (you know - visiting family or attractions) to stock up.
(I am not advocating tobacco usage, merely highlighting a perfectly foreseeable outcome).
The same sort of thing (and much harder to stop) occurred at the border of Massachusetts and New Hampshire for both tobacco and alcohol.
Another short sighted policy (this time by a university campus near where I used to live) was to require that all users of the car park (including the staff) had to pay to use it (and it was expensive); the upshot of course was that everyone parked on the streets (including residential) and massively increased local congestion. The car park was always empty except for those with exemptions from the charges.
Such people seem incapable of thinking things through logically, and the same goes for encryption.
Speaking of which, the name of the game is to make decrypting something more expensive than the value of the information; end to end encryption raises this bar significantly (as it should). If law 'enforcement' think something bad is being planned, they can always do what we used to do - you know - surveillance, who is meeting who and so forth. These are things we know work (although not always very well, admittedly).
Having been in electronics and high tech for a long time, I am always amused at some people's (particularly politicians) faith in technology. It is certainly useful, no doubt about that, but believing it stands as a complete replacement for other methods is very silly indeed.
My path to chartered is interesting; the company I was working for at the time ($Big Aerospace Company) worked with one of the institutes that can confer CEng status to show that if you were at a particular level of seniority in engineering (that place was most definitely a meritocracy at least in engineering) then they had the requisite educational background.
They even paid for the chartered process and provided mentoring and coaching for the application forms.
The advantages to them included being able to show a high percentage of CEng in the engineering department(s) to potential customers on bids, and another unusual one; if a chartered engineer is called as an expert witness in the UK (for a relevant topic obviously), their status as an expert witness cannot be challenged (their testimony obviously can be).
Even though I left them a few years ago, I find that at my age, the CEng post nominals are useful so I still renew my registration each year.
I agree that using the term 'engineer' for the purpose of regulation is way too broad.
From the article:
Mills, who has over 30 years of electrical engineering experience at companies like Rayovac, Unitech, Spectrum Astro, and General Dynamics
I am also a chartered engineer but I do not have a degree - however I do have almost 50 years doing electronics (and software and FPGA design) for money at every level from junior mechanic to design authority; I even have my name on a high speed signalling standard. I have had a lot of opportunities in my career and I have taken them.
Not all paths to being an engineer are via university - the late great Jim Williams did not have a degree - are you going to claim he was not an engineer?
Rather like him, I had what I call a 'self directed apprenticeship'; I have designed a lot of interesting things over the years, including flight safety critical equipment (as part of a team which is normal for such stuff) which is subject to a lot of scrutiny, testing and verification (Boeing notwithstanding).
It was not (and is not) necessary to be chartered to work on such things; what is required is to prove you have the necessary skills and knowledge (which is not true of a freshly minted graduate).
It is only after graduation that the real education begins.
When I left a company in Florida (mid 90s) I went to a startup that was designing the same sort of thing (smart payphones) but the design was a clean room implementation. That did not stop the previous company from sending me threatening letters based on 'non-compete'.
A smart payphone ( as it was known at the time) is fundamentally a small embedded computing solution that operates as a payphone and there are only a limited number of ways to do that at least architecturally.
Now Florida is nowhere near to being as employee friendly as California, but even then a non-compete could only be enforced for some very specific reasons.
1. Customer lists. Taking a previous employer's customer lists is clearly a no-no (contacting those customers in a social sense is a bit more hazy - "I would like to meet you for a round of golf" sort of thing). Typically this for senior executives and sales staff.
2. Specialised training was provided which you will be using at the new place of employment. They never gave me any training at all (and I am sure they got the better part of any knowledge transfer which they admittedly did pay for). I very much doubt that the fruity outfit could give Gerard Williams any meaningful training in integrated circuit design (he was hired because he was / is an IC design guru).
3. Trade secrets; well, in my case I responded that there are numerous ways to make a 2 wire to 4 wire converter (which is a key item in a landline phone) and many of them had been documented in data books by the silicon vendors trying to attract engineers to their solution. I was also using a different methodology for the processing. voice prompts and so forth (using a processor that was not already 25 years old).
There was one other reason that I do not recall (but really could not apply to engineering staff).
In general, even in the southern states, no agreement can prevent you from working in your own skill area (unless they pay you for the two years they think they can insist on).
After my lawyer responded they backed off (the letter rather dripped with sarcasm about their 'ancient' technology) but that sort of thing was going on then and continues to this day particularly in technology companies.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
