Week 9 - HCI

 HCI

The bad

Ethiopian Airlines 302

Probably one of the most disastrous plane accidents in the recent years, the Ethiopian Airlines 302 flight was one with a very, very short life. The plane in question was a Boeing 737, which is a rather important detail to note. Most notably, it turns out that six months before the aforementioned accident, another Boeing 737 had crashed, the reason being a new MCAS automated flight system. Even though there was very heavy backlash to the plane being kept in service after that, it was neglected and thus, the second accident happened. 
What happened was very simple - despite the plane managing to take off, one of its angle-of-attack sensors (A sensor that mostly measures the yaw of the plane) malfunctioned. Merely a minute after takeoff, after the additional takeoff flaps had been retracted - our lovely friend MCAS took over and apparently shot the plane straight into a diving position. The problem with the MCAS system was that it relied solely on a single sensor - which made it very, very prone for errors due to not checking for any sort of redundancies or backups. 
    Because the system itself was ill-known, not a lot was known on how to deal with it, other than an emergency response technique provided after the first crash caused by the MCAS system. Merely turn off the electronic system for the MCAS - it's that simple! Except, it was not. Flipping the switch also disabled the motor that would help recover control of the plane, and manually overriding it was nigh-impossible due to the aerodynamic forces affecting the trim. After having no success trying to manually overcome these forces for a few minutes now, the pilots reengaged the electric trim system - and thus also the MCAS, which instantly shot the plane into an even further dive - resulting in the plane crashing merely six minutes into its flight.
    The system was a bit of a silly one overall, only having been designed to make the plane feel more like a previous model in terms of handling, despite the larger engines with different positioning. A mere convenience feature, but it was given such immense control over the plane that there was nearly nothing the crew could do, especially due to the lack of a good way to shut the system down - probably the most important lesson to take from here.

The good

Firefighter Exoskeletons



    In my opinion, one of the most interesting accessibility technologies is one devised for firefighters (and soldiers). Despite not being for people that are already disabled, it is an important advancement in technology that sounds like it is straight out of science fiction. Rather than replacing a limb or helping someone disabled 'keep up', these systems instead heavily help heavy-duty operatives on the field further enhance their capabilities and be capable of getting access to places others would not be able to with the gear needed.
    The systems are usually "air-powered", having a few compressed air tanks with the help of pneumatic pistons make it a lot easier to move around no matter the load that the wearer is carrying. Unlike the previous example, there is also an efficient failsafe (a quick release) mechanism implemented into the suit, as should be the case with anything that helps a person accomplish a task - it should always be supplementary and optional, never forced on the user. 
    Despite not helping prevent any accidents or something direct like that, an exoskeleton like that can definitely save a lot of lives and make the job of firefighters that much more efficient, especially if it gets to be proven safe over a longer period of time. 

    Sadly there were no IT related examples - they were all just extremely mundane or difficult to find, but I feel like there are lessons to take from these when implementing IT solutions. Something does not have to be directly word by word related to be useful for a person, and seeking for solutions from other fields is one of the first things one needs to learn ;)

Comments

Post a Comment

Popular posts from this blog

Week 2 - Failure.. and success!

Image
 Academset      Technically just a more advanced version of the original Computing Center for Collective Use, the Academset was one of the only few examples of a 'decent' network structure during the Soviet era. Initially built only to serve the staff of the Leningrad Scientific Center, it began expanding during the late 70s, when various other institutions (such as factories), started becoming integrated into the network. After that point, it started growing more and more until it officially became the "Leningrad information-computer network of the SSSR" and was fully fledged into its 'final' iteration - the Academset, which also established links between the satellite countries under the Soviet reign.       The network had several issues, most notably the usage of the OSI protocol demanding a high amount of main memory from the central computers. After the fall of the Soviet union, the mainframe of the network was destroyed and Russia gained access to 'g
Read more

Week 15 - Ethics

 Ethics Act Utilitarianism      Act utilitarianism is the single most beneficial theory in the world, period. It narrates that the 'right' course of action in any situation is one that would grant the most overall positive net gain to every party involved (or the least negative gain). This means that in every case, following the theory would provide the most good - being, on a surface level, the clear cut winner. However, it skips out the individual part - as long as one person's individual suffering would pay for a multitude of other people being happier, then it is all good in the eyes of this theory. Furthermore, it is very difficult to quantify just how 'valuable' an action is to any given person, as everyone has a different measuring stick and there is a whole lot to leave for interpretation in these scenarios. But how does this tie into IT?     Well, for this topic, I will sadly have to be as bland as one possibly can be and talk about self-driving cars. I kno
Read more