Posts by SCP 169 publicly visible posts • joined 16 Aug 2016
The F-14 Digital Flight Control System upgrade of the 1990's in part addressed issues such as flat spin departures and carrier operation challenges.
It is fair to say that the F-14 at the time of MRCA/Tornado inception did have issues, so saying it would have been a better choice is a debatable matter. Subsequent Tornado operational use was generally favourable so it can be considered a successful aircraft design.
(a) it needed a number of unlikely things to all happen
They've made it sound a bit like this, but read it again while assuming: ...
Or break out the tinfoil hats and consider ... there is a deep mole operating inside the inner sanctum and they needed a plausible route to exfiltrate the key without revealing their presence.
Footnote: Having been reminded of this I checked my more recent copy of LibreOffice and found it had a whole selection of autocorrects in this vein using the style ":alpha:". (My copy of MS-Word is a bit more dated and doesn't seem to have this).
Amongst LibreOffice's collection are things like ":_2:" and ":^2:" for subscript 2 and superscript 2. Look to be extensive and consistently structured making them fairly easy to remember (or guess). Well done to whoever did that bit of work.
Humans err, things break. These are the inconvenient truths of the real world. The key thing is that when these things happen we don't want the system to fail catastrophically.
Aviation (and some other fields) have got to a stage where catastrophic failures are rare. Those that happen are investigated thoroughly and have processes that aim to ensure they are not repeated. However, to meaningfully drive continued improvements it is necessary to flag up and address those cases where things went wrong but were not a catastrophe. In this respect the aviation industry culture of "no blame" reporting helps flush out the smaller things that could be the harbingers of doom.
And there is still more chance that the dumbest of automation will turn the lights on before they do.
Ah relays - more heavy duty wiring, extra manufacturing costs, lower reliability. Fantastic.
If you want the vintage motoring experience that's fine, I am happy to leave it in the 1970s.
Mistakes with bus architectures have been made, but modern cars still outperform their predecessors - including in security.
But, sadly, there do seem to be a number of them. And, despite flashing full beam at them repeatedly and after passing them flashing hazard lights they continue onwards oblivious.
Some automation falls into the category "nice to have" (and YMMV) - but I am perfectly happy to have some nice things. And if there are complaints to be made about modern cars I will save mine for the awful interfaces that require you to take your eyes off the road and look at an interior screen in order to figure out what mode the button/dial you are pushing/turning is in.
I'm having a bit of trouble groking why the headlights are on ANY bus.
Well for differing values of "need" there are advantages. Not having to have large power cables running too and from mechanical switches (sited in locations convenient to the driver not the wiring loom) along with those for all the other controls makes builds easier (and cheaper). Then you get all kinds of automation being more practical:
- auto lights on/off for dusk/dawn/poor weather;
- auto main/dipped beams;
- extended courtesy lighting (leaving lights on while you get out of the car and to your door);
- flashing lights on unlock (to help you locate your car if you forget just where it is);
- lamp/LED test at ignition on (check it draws the right current);
Whilst a miscreant might find a way of staying under the radar for a particular iteration of an AI system once the AI has been updated to detect the malicious code it can process the whole software base much more efficiently than a system that relies on human expertise.
This still leaves the challenge of initially detecting the "new" malware technique and training the AI system - which is also the case with human expertise based systems.
The first part of that challenge is not necessarily entirely one-sided. To exploit the malware the malicious actors need to get it into target systems and interacting with their command, control, and data collection systems. The big operators (major APTs) are subject to a great deal of attention from the cyber-security industry (as well as government organizations and university research centres) so there are multiple ways their activities might be discovered - and once that is done the process of determining how they have breached security should be greatly aided by automated techniques that can anayze large code bases efficiently.
Training AI systems is ongoing research - not all aspects are good news (we have seen articles hereabouts about methods of malciously subverting training models in undectable ways, but this is adding to our knowledge.
AI systems could (and probably will) be used by malicious actors and this will probably advance the "script kiddies" technical sophistication - but they, and the more technically competent APTs, will also face the challenge of keeping their AI system training current with a potentially fast changing battlefield.
We have also seen articles about ChatGPT and how aspects of its creative output can seem impressive but also at times very dumb. It still seems that using AI to be creative is much more challenging than using it in a data processing role - suggesting that AI technology favours the defence team rather than the offence.
Reminded me of a building at my former place of work. Identical switches for the door release and lighting (for the floor) co-located in the same twin switch panel. Repeated shouts of "turn the lights back on" at the end of the day as people hurried out. Eventually someone made a cardboard surround to highlight the door release.
(though it did not make it clear it was the door release (so a second "fail") it did make the two switches more distinguishable so people learnt which one to use more quickly).
I also recall stories that at the 3-Mile Island NPP the operators decorated various blandly similar controls to make them more distinguishable.
It's as though the whole subject of cognitive ergonomics is ignored in favour of some subjective artistic styling.
Whilst the disparity in the cost/benefit figures might question the value-for-money to the Government, it does not imply that it will "line the pockets" of BAE Systems.
The projected benefits are not to costs incurred by BAE Systems so subtracting the two figures tells you nothing about the benefit/loss to BAE Systems.
It is not entirely clear (in the article) whether the accounting base for "whole life cost" and the benefits are the same (for example the benefits might be only those accrued over a shorter period).
"... superior to MIPS, it doesn't suffer from its weaknesses like branch delay slots ..."
Using the branch delay slot (or load delay slot) was a deliberate architectural decision (and not just for MIPS) to allow compilers to optimally sequence instructions to achieve a goal of RISC architectures (an instruction completing each clock cycle). It also meant that by putting responsibility on the compiler/author a good deal of simplification of the pipeline silicon was possible; win-win.
Whilst this does mean that you could write "nonsense" code (e.g. putting another branch instruction in the branch delay slot) this does not seem greatly worse than many other forms of nonsense you could write (along the lines of i++ = i++ in C). Being nonsense the archiecture specification declared that the results are unpredictable - but not unbounded; it could do either of the branches but not some random thing.
In some ways this architecture seems preferable to the speculative execution optimization techniques of recent times in which a great deal of silicon and design complexity is expended on trying to execute other instructions out of order but holding off on any potentially adverse effects until it is certain that the instruction is due to be executed. This led to a whole raft of security vulnerabilities being discovered with such architectures and people hurriedly rolling things back.
By making the execution of the instructions in the branch delay slot an active part of the execution thread, that thread takes the consequences of that instruction (e.g. any exceptions that instruction causes) - simplifying the processor execution model. Where I would have a concern is if the architecture made unbounded behaviour practical.
"Unless this technology enables tailless airplane it's not useful, at least not for the military."
Nor will it slice a pineapple - so what! (see Babbage if you want to know).
The issues of yaw stability and yaw control in rudderless planes are a different area of research and a great deal has been done in that area since the advent of digital flight control (and even before that with analogue stability augmentation systems).
Vortex generation and boundary layer control can cause profound aerodynamic effects, so it is reasonable to suppose that it could provide yaw control. At some point that will need to be demonstrated with the use of suitably designed aerodynamic structures - but there is no need to do it now. This work is building on previous research by taking it to a full-scale platform, there is no need to address rudderless control (unless it becomes a particular aspect of the research). There are probably many more pressing areas of this technology to research.
It will be interesting to see how much vectoring of the airflow over the lateral surfaces can be achieved and how well that would support effective yaw control. (It might already have been done - I haven't kept up to date with the research work. Another topic for the 'to do' list).
Materials science is an interesting research area - I recall reading about the use of adaptable surface texturing to control vortex forming as a means of aerodynamic control (unfortunately I can't recall the project names).
From the UK side of the pond the work on FLAVIIR and MAGMA are relevant and illustrate some of the work being done at both Cranfield University and University of Manchester.
NIST have identified a future need (Quantum Resistant Cryptography) and is following its process for creating a standard.
Just how is this "rushing it"?
What should they be doing differently that would mean they are not rushing it (but also not fumbling the ball by failing to keep ahead of the game)?
In general you can use antibiotics against bacterium - but that would typically be when there is an established infection (in an organism) that needs to be addressed.
A vaccine aims to stimulate and improve an immune system response (in that organism) ahead of an infection becoming established.
Generally if an infection has become established then the immune system will already be responding, but there are interesting situations (like cancers) where the threat is not detected by the immune system and vaccines can be used to stimulate an immune system response that deals with the threat.
"The one question I have is how are you going to splice such a cable without blocking the core."
Oh here you go, from a search on Prof David Richardson's publications (from his UoS profile):
"Robust low loss splicing of hollow core photonic bandgap fiber to itself"
2013
https://eprints.soton.ac.uk/370812/
I expect that there are a great many interesting aspects to this (it is not an area I am familiar with), but splicing does not look to be a show-stopping problem - I have seen papers from 2013 discussing it.
While not addressing splicing in particular the following 2020 article gives an introduction to HCF:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7695690/
It would seem that Corning have got solid fibre close to the theoretical limits; HCF offers an approach that might have further potential. Lumenisity seem to have moved the technology from research quantities into commercially useful (for some applications) quantities. ISTR there were some BT trials starting a couple of years back. There is probably a great deal more work to be done, but to build up a commercial business requires investment - Microsoft might have made an astute move.
Of course there can be many a slip twixt cup and lip - but I hope that it turns out well and provides a significant breakthrough of fibre optics research moving into widespread use.
"... but eight times more lossy ..."
Where did that information come from? Research (University of Southampton) published in 2020 had HCF comparable to and better than conventional fibre, with further improvement anticipated. (ref https://www.southampton.ac.uk/news/2020/11/hollow-core-fibre.page)
"The nice thing about solid fibre is that the "wall" is from a high refractive index (the core) to a low index (the cladding) - which means you get TIR - total internal reflection. The attenuation is just then down to the transparency of the glass, which is amazingly good."
HCF uses wave-guide principles to keep the beam in the fibre's channel and which has an even lower attenuation.
I seem to recall there has even been work done looking at transmission of power (high energy laser) over HCF.
I thought the F-35 radar was Northrop Grumman kit! Are you thinking of the EW system?
BTW I think the decision on not having Ada on F-35 was not a BAE Systems one - that decision was taken at a much higher level.
Which is why you wouldn't do it that way. One of the key reasons for man-in-the-loop is authority to release weapons. Once that is given the automated systems can do the necessary flying and coordinate offensive and defensive activities. Others have described some of the capabilities of systems that are already operational and the flexibility that provides in engaging targets. Automated systems can react much more quickly, consider many more possibilities, and operate more precisely. Even in manned systems a great deal of automation is used to take the load off the pilot - leaving him to manage the battle.
There are different levels of automation, for example - None, Advisory (pilot performs the actions suggested) , Recommendation (pilot gives permission and the system does it), Do it and Announce (pilot can intercede if they need to), Just Do It. Historically, for many reasons, the authority allowed to automated systems has often been limited, that is changing.
Whilst there is a role for cheap-and-cheerful systems, high capability systems also have a role they can play - the key thing is to get your force mix right.
I disagree with the first part of your reply but mostly agree with the second part (the crew do have to handle things when the automated systems can't).
For any system to be acceptably safe it must continue to function adequately even in the presence of likely faults. This means the crew must be an integral part of the design. Handling faults can be a tricky part of system design, particularly when crew workload is itself is a safety concern. My comment related to the design constraints commonly placed on many current automation systems in dealing with faults and when the crew must become involved - not the total design of the system.
Systems with higher degrees of automation, authority and fault handling can be (and in some areas have been) designed and implemented and these typically reduce crew workload and improve overall system capability and safety. But as always there are trade-offs.
You need minimum 2 rested and alert pilots for each flight
You can find cases where even this is not enough. For example:
https://en.wikipedia.org/wiki/1999_South_Dakota_Learjet_crash
In this case (entire crew incapacitated by hypoxia) a more advanced automated system could negotiate with ATC an emergency landing and safely land the aircraft.
Do not rely too much on automation and then advocating one-pilot operating an a/c?
The first would be in relation to the currently deployed forms of automation, the latter would be in respect of addressing a future form of automation that would make single pilot operation practical and safe.
Current forms of automation are often designed around principles that rely on the piloting crew as a fall-back - this allows the automated system to remain much simpler (because it does not have to deal with difficult cases). It also means that the automated systems are given limited authority as they rely on the piloting crew to arbitrate between differing demands on what needs to be done with the aircraft.
The challenge, to achieve single pilot operation, is extending the capability of automation in dealing with more situations and establishing a basis for giving the automated systems more authority (part of that being that they can be shown to be acceptably safe).
It is worth looking at the advances made in military fast jets - a very demanding single pilot operation. Much has been done to automate the flying leaving the pilot free to manage his mission. Not everything reads across directly to large passenger operations, but it does give some indications of what automation can do. (And remember that digital fly-by-wire originated in the military/space programmes).
It is also worth considering that there is a significant air freight sector which might be better placed to adopt new automation.
I presume you're talking about AI-based automation. Assuming it can learn, the more-important question is, "Is it learning the correct lessons, and not discarding (pruning) previous correctly-learned lessons?
[Resubmitted due a grievous typo not spotted in the edit period]
There has been quite a lot of research into adaptive and non-linear flight controls - it does not need to be based on AI. One approach (IIRC) was to seek to establish effective control by comparing the actual aircraft response to a high-fidelity model and using the discrepancies (along with other available information) to adjust how effectors were used - this gave a means of adapting to faults in the system.
While many very interesting and useful things can be done a major difficulty is that such systems are very difficult to certify in the current regulatory framework (particularly that for high-assurance software).
Caution is a prudent virtue when dealing with safety matters, but it should not totally stifle development. At one time digital flight control computers, and the software running them, were novel and a cause of concern - but are now fairly common and accepted technology. Generally the progress in flight automation has seen major improvements in flight safety; but that progress has often been at the behest of commercial aspects rather than altruism.
If the stories about 'Olympic Airways 411' are true, the only thing that stopped a disaster was a bloke with experience - something that AI, and it's coders, cannot have (Especially as the human through the rules book out of the window..which AI would never consider doing!)
There are also tragedies like Kegworth where people got it wrong. Decisions on progress in the use of technology need to be based on all the data, not cherry picked cases.
(In the Olympic case it is also claimed that human error led to the turning off of the water injectors)
I seem to recall there was quite a bit said when UK police tried (or did) use Covid tracking app information, so I am not sure that there is totally one-side treatment of nations on this sort of topic. Indeed one of the regular topics on The Register is security and numerous states, companies, and general user "stupidity" have been called out.
In this case Qatar is insisting on use of applications which have a security implication for users; it is a relevant news story, and if the same situation regarding apps had arisen with the World Cup being held in the US I am confident The Register would have covered it equally as well without fear or favour - it is not as though the TSA gets a free pass on this site.
I was just pointing out the folly of advocating a solution that has (by the advocate’s own argument) an underlying basic and catastrophic flaw.
And C [and other] compilers have code generation flaws, but that does not make using High Order Languages (for some value of High) a bad decision or reduce us to "building on sand" - though we need to remain cautious about the degree of trust we place in such things.
The key difference between writing software in a language that exposes a greater risk of errors, or using a language where some underlying part of the toolchain is still dependent on that riskier language, is that the former approach exposes the entirety of the new software to those risks (and there is a long and sad history of software writers continuing to make the same sorts of mistakes as has been happening for decades). The latter approach moves more towards the "Correctness by Design" model in which it is not possible (or at least diificult) to make these mistakes during the implementation process.
It remains a problem that tools such as compilers (or libraries) might introduce errors - which is why you need to remain careful about the degree of trust you place in them (e.g. by careful vetting and control of your choices, and the degree of testing of the final product).
You must be an Englishman as you are embodying what Babbage railed against ...
"Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to find a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible: if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple."
:-)
It is worth keeping in mind the aphorism "Perfect is the enemy of good" - the suggestion from NSA does not address all problems, but it does address a recurring problem in "everyday" software.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
