Wednesday, November 10, 2010

Rhetorical analysis

My articles from the IEEE Computer Society have all followed roughly the same structure. A problem, a hypothesis, and what the future of it may be. There may be a new technology coming along to replace an old one, which they explain. They then go into details as to how it can be improved, and why. Finally, they give us a test of how the new technology might look and feel when it actually gets here. Most of the articles followed this same structure, especially being that they were all scientific entries about computer technology.

This brings up the next point, reference. As mentioned above, no technology is scrapped, only added upon. In one post I talk about Web 3.0, which is Web 2.0 upgraded. Each article mentions how the technology can be improved upon, never just thrown out. In the oil spill article, they look at the problem and find out how to fix it, as opposed to simply creating an entirely new software system for oil rigs.

The language used in each article can be read by anyone who is familiar with technology. Some of the content may only make sense to someone in Computer Science like me, but most of it is for the layman. All of the writing if scientific, there is really know humanistic or philosophical point of view. It is all to the point and laid out easily.

Although some articles were difficult to fully comprehend, even to me, I feel like the scientific journals provided were interesting and really brought life to my major and where it is going...

Did computer software cause the BP Oil Spill?

We don't have access to all the data from this incident. However, Transocean's interim report, submitted to Representative Henry Waxman's committee in the US House of Representatives on 8 June 2010, stated the following under an "Action items/work needed" section: "Full control-system software review. Software code requested from manufacturer for investigation." Apparently, in studying the disaster, there's speculation of a software connection.


Offshore oil rigs comprise dozens of complex subsystems that use embedded software or are operated under software control. For numerous reasons, each system is a potential point of failure. For example, three rigs with the same design built over four years can end up with different equipment and software versions that might not integrate as expected. This could also lead to serious configuration-management problems.

Another problem is that much of the software residing in or controlling components is routinely delivered well after the equipment is onboard the rig. Engineers test the interfaces at the last minute, if they even test the software at all. Equipment interfaces thus present the weakest link in offshore oil rig systems in terms of reliability and safety, because the industry lacks interface standards and sufficient testing methods.

We'll learn more about software's role in this disaster as additional evidence surfaces.

Fallen behind yet again... Also, ROBOTS!!!

A miniature helicopter enters your workplace through an open window. It avoids alarms and security cameras as it navigates its way to your boss's office. It removes a flash drive from her desk and deposits a substitute, possibly even bearing a potent virus, so the crime goes undetected.

This would have been science fiction until recently but now it is part of the Sixth International Aerial Robotics Competition, held at the University of Puerto Rico in 2010. While this is a wonderful challenge, it also serves as a forceful warning of crime’s coming robotization.

Soldiers now can launch missiles from unmanned aerial vehicles (UAV's) without ever being in the line of fire. But what happens when the wrong hands get the same technology? And what if there's is better? As AI and robots advance these are all things that need to be taken into account.