Autopilot
I guess too many people have seen "Airplane!".
648 publicly visible posts • joined 16 Apr 2021
Not only that, SN15 only had "feet" for landing rather than lander gear with shock absorbers - they were designed to crush on landing, and would not completely protect the hull from damage.
Another "clue" that they were never intended to fly again was the lack of support mechanisms to "safe" Starship once it was on the ground. In fact, it was much better when they were destroyed as they could just sweep away the bits - with SN15 they had to wait until all of the residual fuel had boiled off before they could approach.
Is for the provision of services via fixed-price contracts*, not for the supply of pork to fill the barrel.
Sure, they also take advantage of available tax benefits, grants and awards, but these are insignificant when compared to the amount that Musk, the shareholders and other investors have put in over the year.
* Some of which are for R&D, such as on-orbit refuelling - though I doubt the contract will cover the actual costs for this.
Should the firmware for a safety-critical sensor be made available so the device can be hacked?
If so, how does anyone who ends up with one of the devices know that the software has not been modified and that it still satisfies its functional safety requirements? Who is legally responsible if the failure of a modified device leads to an accident?
Or are we only talking about firmware in "consumer electronics"?
But this isn't it, and open-source authors should not be covered.
However, any company that uses open-source within a commercial product should be responsible for ensuring that it is appropriate for the job - which means ensuring* that it does not introduce security or safety vulnerabilities into any product that they place on the market.
* "ensuring" does not mean that it will be defect free, as it is generally impossible to show that is the case. What is required (from a legal perspective) is evidence to show that the chance of a failure is as low as is reasonably practicable (which depends on the the cost/value of the product and costs/risks associated with failure) - which basically comes down to ensuring that development complies with a standard and that artefacts are produced to demonstrate how compliance with that standard has been achieved.
I'm sure there will be a lot of "but that slows us down" and "that stifles innovation", but it doesn't have to. Sure, it will have an impact up front, but it does not have a negative impact on timescales if appropriate processes are used.
The figure did include the boxes, relays, fuses, connectors and the like that were needed in the days before functionality was moved to electronics (there was some for fuel injection, but that was the exception).
This was "for real", and was for a top-of-the-range Merc (I don't remember the model). It was disassembled by the OEM I was working with and placed on large, wooden panels all along the walls of one wing of the electrical design centre for "competitive evaluation" (the OEMs exchanged models as they all did this, and this made the process a lot cheaper)!
Like the Kia Hack
Back in the early 2000's I designed a CAN "firewall" that basically did that - though it was really there to prevent experimental / development / prototype hardware from corrupting the powertrain CAN.
It's not easy to do though, as you ideally don't want to introduce latency into the messages - I managed to get it down to about 12uS, which was about as good as you could get at the time using "store and forward".
When I was contracting with an automotive OEM about 20 years ago, it was not uncommon for the (pre-CAN) wiring harness (+ switches and the like) to weigh in at close to 100Kg. The amount of fuel needed to keep accelerating that mass is not insignificant - especially when the design is on the edge of legislated fuel economy figures.
Not really, as CAN is a hard real-time bus (which means messages are very time critical). For example, I work on systems where a specific CAN message is sent out 1000 times a second and is used to trigger events in other nodes (setting outputs, sampling inputs). Most nodes run on low-end microprocessors (which are very cheap - you don't want to have to spend an extra few £/$ per node when there are lots of them).
"Transcript" of a conversation at a place I once worked (names "randomised"):
Eve: "Hi Steve, I see you're having trouble with that flashy Toyota Supra again"?
Steve: "What do you mean"?
Eve: "They're loading on to the flatbed now".
Steve: "****".
The car had all sorts of locks and immobilisers, but it still went missing.
I'm not sure how that would help here, as CAN doesn't have anything equivalent to MAC ids?
It's not that easy to protect CAN messages:
1) Some form of payload validation/encryption could be added - this is not really practical, as a lot of systems still use the original CAN protocol, which only supports 8 byte payloads.
2) Some more recent CAN hardware allows the authorised sender of a particular CAN identifier (message) to invalidate any attempt to generate a spoofed message (basically, the "owner" of the identifier intentionally corrupts any transmission that it does not initiate). In this case, the thief would have to disable the security node before the spoof would work.
3) Split the vehicle architecture so that there are multiple CAN buses (this is quite often the case anyway), and ensure that it is not physically possible to access any bus that is security-related from outside of the vehicle. This would not prevent this type of attack, but it would mean that the security system would have a chance to activate some other defence mechanism as it would be able to detect an intrusion via the alarm system.
16.5 million pounds of thrust - where's the metric for the rest of the world?
Though I think we need a new Reg unit of measure - "UK power grids"; Starship will, for the first 2.5 (ish) minutes of flight, be producing more power than the whole of the UK power grid can provide running flat-out.
My "local" branch is now only open from 09:30 to 16:30 Monday to Friday, so the only way anyone who works out of the area can get to it is by taking time off.
I can no longer think of a reason not to dump them and move everything to an online-only bank.
I recently tried to open an account for a business with a different bank in the same town (during the day), and was told I would have to make a 1 hour (each way) trip to another branch as local branches are no longer able to process business applications. I went with Starling instead - everything done online in a matter of minutes with no paper form-filling. It's time for the dinosaurs to go extinct...
I had this appear earlier on in the week.
First thing I tried in response to the "Can I help you?" message was to ask it "How do I remove Bing from Skype".
That didn't work, as it wanted me to accept T&C's of use before it would reply.
Right-click, delete on the bot in the contacts list seems to have sorted it (Mac version).
I was once contracting for a large company. We were all sitting in the large, open-plan office when the "get ready to leave" alarm sounded (it was a big place, and a fire alarm in one block would set this off when it was triggered as a "heads-up").
Shortly after, we noticed a slightly unpleasant smell, followed by sore throats, coughing and streaming eyes. We unilaterally decided that, as it appeared as if we were being poisoned, it was probably a good idea to put on our coats, pick up our laptops, and evacuate the building.
Many minutes after we left, the alarms changed to "evacuate" - a transformer in a large UPS had got upset, and the combustion products were getting sucked into the ventilation system.
The permanent staff were forced to go though mandatory fire drill "retraining" as they had clearly failed to follow the procedures by evacuating before they were told to do so. They were also told that putting on coats and taking laptops was against the evacuation policy, which they had just been told was not in force when they left the building...
Safety-related projects often have a requirement to achieve 100% code coverage. I've seen some where automation is used to generate the test vectors, and they are blindly accepted without verifying that the results are actually correct ("but we've got 100% coverage") - all that has been proven is that the code works as it has been written, not that it works correctly.