HW4: Chapter 11 & 12

Ch 11 & 12

What is the common characteristic of all architectural styles that are geared to supporting software fault tolerance? 

The three fault-tolerant architectural styles outlined were protection systems, self-monitoring systems, and N-version programming. Each of these systems uses software & sometimes hardware diversity deal with faults. Protection systems can use separate sensors and software to monitor the system and the environment for potentially unsafe states and attempt to move to a safe state. Self-monitoring systems use multiple versions of software and hardware to complete the task and the system compares the results and makes a decision based on these comparisons. Finally, N-version programming uses multiple versions of software, developed by separate teams, to interpret and act on the same input and then compares the results. If a fault is found the fault manager deals with the faulty unity by attempting a repair or removing it from the system for repair.

It has been suggested that the control software for a radiation therapy machine, used to treat patients with cancer, should be implemented using N-version programming. Comment on whether or not you think this is a good suggestion.

Initially, I leaned towards a protection system as the ideal in this scenario but after a bit of contemplation on the nature of radiation therapy, it seems impractical. Since the protection system uses sensors to monitor what is happening and radiation therapy (in my limited experience) relies on short bursts of radiation that a protection system would fail to stop. An N-version programming system would be a better option as the system is not as complex as say, a plane, but still requires safety checks. The diverse software should lead to more accurate output results and limit the likelihood of a safety hazard.

Explain why all the versions in a system designed around software diversity may fail in a similar way.

 As individuals on different teams are often similar in education and culture there is an increased likelihood that the same mistakes in design and solutions will be made. Additionally, if the requirements for the project are incorrect in some form or fashion, the same mistakes are likely to occur. Finally, the specifications for the system may not be detailed or specific enough and lead teams to come to the same conclusions and make the same mistakes.

A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded, or if the train enters a track segment that is currently signaled with a red light (i.e., the segment should not be entered). There are two critical-safety requirements for this train protection system: 

 The train shall not enter a segment of track that is signaled with a red light.
The train shall not exceed the specified speed limit for a section of track. 

 Assuming that the signal status and the speed limit for the track segment are transmitted to on-board software on the train before it enters the track segment, propose five possible functional systems requirements for the onboard software that may be generated from the system safety requirements.

 The system will include self-check software to test the sensor system that detects the trains' location and the red light sections of track. The self-check will also test the sensor for speed.
The self-self check software will execute the tests once per minute.
If the self-check software detects a fault in either system, the conductor and train dispatch will be notified.
The system will include a manual override of the speed controls.
The software will not allow manual operation at the start of a trip without higher-level authorization. (This would still allow for manual operation in the event of a fault mid-trip but not at the start).


Comments

Post a Comment

Popular posts from this blog

HW10: Chapter 5

Image
System Modeling 5.3. You have been asked to develop a system that will help with planning large-scale events and parties such as weddings, graduation celebrations, and birthday parties. Using an activity diagram, model the process context for such a system that shows the activities involved in planning a party ( booking a venue, organizing invitations, etc.) and the system elements that might be used at each stage. This diagram does not include food, drinks, decorations, chairs, equipment, DJ, photography, or the other myriad of things possible at a party. It simply goes through the process of determining the size, date, venue, guest list, and invitations.     5.5 Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about a...
Read more

HW11: Chapter 6

Image
This is my take on the conceptual and process views of 3 different machines. I found myself having difficulty distinguishing between the two in some instances. I seemed to want to go directly to the process view and skip the conceptual view altogether. I'd like to find some simple, real-world examples of conceptual and then process view diagrams of the same system to see the differences. 6.4: Draw diagrams showing a conceptual view and a process view of the architectures of the following systems: A ticket machine used by passengers at a railway station. A computer-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time. A robot floor-cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions. %3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2...
Read more

HW26:Chapter 24

24.6. Explain why program inspections are an effective technique for discovering errors in a program. what types of errors are unlikely to be discovered through inspections? Program inspections are essentially peer reviews of code that take place during development. Teams collaborate and walk through code line-by-line in search of bugs, exceptions, erroneous conditions, in house compliance issues, as well as things the team deems worthy to discuss. They are considered good practice because they bring together a diverse set of engineers to review the code and it can also help create a company culture that understands the importance of acknowledging errors and moving forward to improving. Sommerville states that during program inspections, there is broad use of checklists to help guide the process. These checklists are typically language-based and cover a wide range of common errors found in the past. This could lead to a reliance on such lists and overlook some more technical issue...
Read more