Search

The choice of programming language depends on a number of factors, such as efficiency and maintainability. With the predicted increase of the soft error rate in coming years due to technological improvements and the popularization of energy-saving techniques, the responsibility of tolerating transient hardware faults is no longer solely on the hardware-side, but is becoming more and more a software problem. Therefore choices taken throughout the software development and compilation process, such as the used programming language, are now a factor that should be taken into account. This paper evaluates the impact of the programming language in the sensitivity and vulnerability to soft errors of an application, through extensive fault injection campaigns that cover 5 benchmarks over 7 programming languages, considering the most common implementation. The results show that both the programming language and workload have a significant correlation with the occurrence of failures due to soft errors. Furthermore, since execution time varied noticeably across programming languages, applications developed in less-efficient languages showed a higher vulnerability time window in which they may be affected by soft errors.

Severity levels, e.g., critical and minor, of bugs are often used to prioritize development efforts. Prior research efforts have proposed approaches to automatically assign the severity label to a bug report. All prior efforts verify the accuracy of their approaches using human-assigned bug reports data that is stored in software repositories. However, all prior efforts assume that such human-assigned data is reliable. Hence a perfect automated approach should be able to assign the same severity label as in the repository --- achieving a 100% accuracy. Looking at duplicate bug reports (i.e., reports referring to the same problem) from three open-source software systems (OpenOffice, Mozilla, and Eclipse), we find that around 51 % of the duplicate bug reports have inconsistent human-assigned severity labels even though they refer to the same software problem. While our results do indicate that duplicate bug reports have unreliable severity labels, we believe that they send warning signals about the reliability of the full bug severity data (i.e., including non-duplicate reports). Future research efforts should explore if our findings generalize to the full dataset. Moreover, they should factor in the unreliable nature of the bug severity data. Given the unreliable nature of the severity data, classical metrics to assess the accuracy of models/learners should not be used for assessing the accuracy of approaches for automated assigning severity label. Hence, we propose a new approach to assess the performance of such models. Our new assessment approach shows that current automated approaches perform well --- 77-86 % agreement with human-assigned severity labels.

Introductory program courses often have a final project. The development of a game using programming languages learned is possible choice for this project. A large Midwestern public university has been assigning a programming project at the end of it's first semester, first-year engineering course. Previous projects have included an IR detection program and programming a train scenario. Recently, faculty have been piloting a game software design project in these courses. Student survey results have demonstrated that students prefer the game project to the other projects for many reasons including they are more enjoyable and they help develop necessary engineering skills. The results from this pilot have lead to many questions that will be explored in future studies.

We explore what can be said about the detailed modelling of problem solving ability via a stochastic semantics of a theory of software problem solving, and end with an invitation to discuss possible experiments that may lead to the practical characterisation of the problem solving ability of software teams.

The bubble display controls the sorenoid valve by PLC, generates the bubble in water, and shows the character and the figure with it. It is chiefly used in the several events. A present problem is a software problem and the operation when the display is changed because of its cable communication. It is that the displayed things are limited. Moreover, there is a fault that PLC is expencive. At this present research, both the application to communicate the data of the character and the figure drawn with the touch panel of the Android terminal with the control part on the bubble diplay by using Bluetooth and the control circuit that controlled the bubble display, were developed from the information. It became possible to output the pattern to the bubble display by drawing the pattern on the application of the Android terminal at present, and sending this to the control circuit.

of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid! My suggestion is simple. Pay only when defined results are provably delivered. This requires several things: ∞ Contracts that release payment only for meaningful results; ∞ The ability to define those results, particularly qualitative ones, and particularly the organizational ones; ∞ The ability to deliver those results incrementally, thus proving capability at early stages and continuously. Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.

We present an architecture and algorithms for performing automated software problem determination using call-stack matching. In an environment where software is used by a large user community, the same problem may re-occur many times. We show that this can be detected by matching the program call-stack against a historical database of call-stacks, so that as soon as the problem has been resolved once, future cases of the same or similar problems can be automatically resolved. This would greatly reduce the number of cases that need to be dealt with by human support analysts. We also show how a call-stack matching algorithm can be automatically learned from a small sample of call-stacks labeled by human analysts, and examine the performance of this learning algorithm on two different data sets.

For an unmanned aerial system (UAS) to work seamlessly within the national airspace (NAS), it must have a way to sense and avoid any obstacles autonomously. This paper describes a monitoring system that has the ability to monitor in real-time both the hardware and software components of the UAS during flight operations and execute any actions that are necessary to handle or prevent any issues that might occur during an encounter with an obstacle as well as during normal flight. The system was implemented and all its capabilities were thoroughly tested using software-in-the-loop (SWIL) flight simulations with real-time sensor data. The results from these tests demonstrated the system's capabilities to identify a component in a critical state, a software problem, or an environmental issue and handle it in order to maintain the Airborne Sense and Avoid (ABSAA) system's full capability.

Defect causal analysis offers a simple, low-cost method for systematically improving the quality of software produced by a team, project, or organization. DCA takes advantage of one of the most widely available types of quality information, the software problem report. This information drives a team-based technique for defect causal analysis. The analysis leads to process changes that help prevent defects and ensure their early detection. The paper discusses the three principles that drive the DCA approach. It considers the impact of DCA on an organization.

The benefits of cross-training in terms of increasing responsiveness to demand fluctuations have been studied extensively in the literature. In this work, we study another important advantage of cross-training due to customer misclassification, i.e. a caller declares to face a certain problem (e.g. a hardware problem) where in fact another problem persists (e.g. a software problem). In call centers that apply no cross-training, misclassified calls need to be rerouted to agents who are able to serve the true problem, whereas cross-training enables agents to serve different problem types which reduces cycle times. We introduce two-type queueing models to study the effects of customer misclassification on cross-training in call centers. We observe that, if only a third of the agents is cross-trained, high increases in model performance can be confirmed, whereas little benefit is added by higher amounts of cross-training. We also study the effects of routing policies on cycle times.

Analyzing, diagnosing, and proposing fixes to problems in complex software is essentially a linguistic activity: we think in languages such as C and English, we analyze written problem reports, we read listings. In cognitive psychology and interpretation theory, the linguistic constraints upon cognition are well established; but with the exception of those authors working within the field of Speech Act Theory, little has been said about how these constraints affect software problem diagnosis or what we can do to overcome these constraints. This paper examines some of the linguistic aspects of software problem analysis, showing how these may contribute to the bad fix, and then describes a change specification procedure specifically designed to help development teams overcome some of the liabilities of interpreting complex software failures.

Summary The paper describes the successful sidetrack of an oil well in the Slaughter Field in West Texas using coiled tubing (CT). Several first-time CT operations performed during this workover include: Setting a whipstock in casing on CT Cutting a window with CT Using mud pulse measurement-while-drilling (MWD) with CT in a "real" well Use of a fluid-operated orientation tool for in-hole toolface changes Successful use of an "autodriller" to maintain weight on bit while drilling Directional control of the sidetracked hole proved to be ineffective due to a surface software problem. The resultant wellbore was not horizontal as planned, but instead closely paralleled the original well for much of its length. However, the previously non-productive well flowed 1000 barrels of fluid per day (BFPD) from the sidetrack following the workover.

We introduce Proteus virtual development techniques into the microcontroller I2C bus communication designs, and take the AT24C02 for example to explain the Proteus simulation software and hardware design circuit of I2C bus communication. Then we analyse the hardware and software problem in Proteus debugging and provide the solution. The Simulation results which is identical with theoretical analysis prove that the correctness and the accuracy of Proteus virtual simulation. It has very important significance in the microcontroller virtual development.

A logic error in the software of Cosmos II results in apparent malsensing of atrial signals at high rather than low sensitivity settings. The paradoxical function was found in 54 out of 87 units tested (= 62%) if the atrial sensitivity was increased and in 54 out of 87 units tested (= 62%) if the atrial sensitivity was increased and the ventricular refractory period was lengthened beyond critical limits that could be defined individually. The problem inherent in both unipolar (66%) and bipolar systems (54%) is attributed to a summation of a physiological signal and internal noise, which has to be detected at the atrial level within a specific timing window to disable atrial sensing for the next pacing cycle. The malfunction virtually disappears if the ventricular refractory period does not exceed 210 msec. It is recommended, therefore, that Cosmos II pacemakers be left at their nominal ventricular refractory value (200 msec).

We describe the case of a dual chamber rate responsive pacemaker (Relay, model 294-03, Intermedics, Angleton, TX, USA) implanted in a 68-year-old male for sick sinus syndrome, which was not working properly when programmed in the DDIR mode, thus determining occasionally a sort of "VVI" pacing. However, the pacemaker performed well when programmed in the DDDR mode. We discovered that this was not a malfunction of a single device but rather a general behavior of this family of Intermedics dual chamber pacemakers (also not rate responsive), caused by a software problem.

ICD Software Error. Loss of ventricular output resulting from an unexpected software error in a dual chamber implantable cardioverter defibrillator (ICD) is reported. A 70-year-old man with a dual chamber ICD implanted for a history of cardiac arrest and infra-Hisian block presented with acute onset of dizziness. He was found to have loss of ventricular output due to an internal software problem. The problem was corrected by software reprogramming via the programmer. This malfunction exemplifies the potential ability to correct current-generation ICD software problems noninvasively, thus avoiding the need for replacement.

Predicting the time and effort for a software problem has long been a difficult task. We present an approach that automatically predicts the fixing effort, i.e., the person-hours spent on fixing an issue. Our technique leverages existing issue tracking systems: given a new issue report, we use the Lucene framework to search for similar, earlier reports and use their average time as a prediction. Our approach thus allows for early effort estimation, helping in assigning issues and scheduling stable releases. We evaluated our approach using effort data from the JBoss project. Given a sufficient number of issues reports, our automatic predictions are close to the actual effort; for issues that are bugs, we are off by only one hour, beating naive predictions by a factor of four.