Property-driven model for finding safety issues开题报告

1. 研究目的与意义

In software engineering process, requirements engineering is a major software engineering activity that begins during the communication activity and continues into the design activity. Requirements builds a bridge to design and construction of software. Most requirements are specified on the assumption that the systems operating environment will behave in an expected manner, while off-normal behaviors (ONB) which are unintended and unusual behaviors can result in critical situations [1]. A causal component model (CCM) approach has been proposed, which can expose ONBs within a set of natural language (NL) requirements. However, there are some limitations in specifying the scope of a safety issue in CCM model, which does not take the properties of components into account. Ignoring properties might result in incomplete analysis of requirements. Therefore, we want to add the property of the components as a model element to facilitate the model for the ONBs analysis. When adding the property of the components to the CCM, we can expose more safety issues than CCM. In additional, it can help figure out the relations between components, which will be helpful in our future work in reducing the redundancy in rules. The figure 1 shows the difference between CCM and property-driven model. The figure 1 shows the difference between CCM and property-driven model.

2. 国内外研究现状分析

ONBs can occur for various reasons. For example, a systems humanoperatorisconfrontedwith an unexpected scenario, forcing the operator toreact in an abnormal way, or the systems sensor data can unexpectedly be outside the range or ofa different data type.TheseONB problems are oftenaddressedfromtheenvironmentalstandpoint,while focusingon thehumanmachineinterface, because human behaviorcannotbefullypredictableandisproneto unexpected behaviors. Many effortshave been made in theareaofoff-nominalbehaviortestingwhichtypically occurs at the end of the development cycleduring software testing, which can involve scenarios designed to expose the softwares responsetoanoff-nominal case.Verma et al.sstudyutilizesoff-nominalbehaviortestcasesfor airplane runway operations to expose possible ONBs. As withtestingingeneral,off-nominalbehaviortestingcan have limited effectiveness because exhaustive testing is not practical.It is not unusual for a reactive systems user to find a bug afterthesystemsreleaseintothefield.Wheninquiries about the user behaviors are made, it is often discovered that the user found the bug by interacting with the systemina way other than the happy paths. Happy paths refer to scenarios under which systems are typically tested and for whichriskassessmentsaremade.However,software systems tend to have more transition paths than are typically tested, and thereare many scenariosthat are not accounted for,inparticularonesthatareoff-nominal.Formal methodscanvirtuallyaddressallpossiblescenariosby proving the correctness of a systems criticalparts,buttheytypicallyrequireaconsiderable learningcurve.Wearepartlymotivatedbytheideaof developing a technique that addresses ONBs while being as industry friendly as possible. A major industry that has invested considerable efforts to address ONBs isaviation where erroneoushuman behavior can have catastrophic results [18]. The aviation industry has triedtoaddressONBproblemsduringtherequirement phase, focusing on anticipating and specifying contingencies (in the form of scenarios) that address potential pilot errors. Neerinex has taken a cognitive engineering approach to addresstheproblembytryingtoanticipatean operators actions and responsestooff-nominalscenarios.Giese andKrugerhavesuggestedaniterativemethodologyto developascenariospecificationfromaninitialsetof nominalscenarios,whichissubsequentlygeneralizedand usedtoproduceadditionaloff-nominalscenarios. Fraccone et al. have used simulation-based models to create off-nominalconditionsforair-trafficprocedures. Scenarios and simulation-based models have also been used toanticipatewhatcontingencieshavenotspecifiedand improvethesystemsrobustness,makingthemmore foolproof.When addressing ONBs from a system standpoint, there are various methods that focus on systems that have already been implemented (in contrast to our method that focuses on the requirement phase). The other methods include fault tree analysis (FTA), event treeanalysis (ETA), cause-consequenceanalysis(CCA)[16],andtheuseofmodel checking. ETA requires historical knowledge of an existing system, whereas we are trying to assess unintended behaviorsfromrequirementincompleteness.FTAusesa cause-and-effect diagram with digitallogic symbols to deal 137CCAintegratesfaulttreesandeventtreestopredictthe effect of a failure scenario. Therearetechniques based on exposinggoalobstaclesthataddressbehaviorsthat produceanundesiredstatebyobstructinganominal behavior.Unlikethesetechniques,ourconcerniswith exposingbehaviorsthatareproactiveinproducing undesired states

3. 研究的基本内容与计划

The scope of this class project is to implement a tool, which helps in identifying safety issues using component properties and CCM model. work time milestoneData collection two weeks 2.15.2019Database creation one week 2.22.2019Empirical study three weeks 3.21.2019Tool implementation three weeks 4.12.2019Table1: Schedule3.1 Data collectionWe will collect the common properties of the components within drones manually. The resource of our information includes the drones list from the IEEE robots and some requirements documents online.3.2 Database creationWe plan to create a MySQL database to save the data we collect.3.3 Empirical studyWe will conduct an empirical study on multiple requirements documents to prove the effectiveness of one approach.Research questions: Can we find more safety issues by using a property-driven model than using a causal component model (CCM)?The independent value of our empirical study is the safety analysis technique, and the independent value of our empirical study is numbers of safety issues.3.4 Tool implementationWe will implement a tool that can automatically suggest properties and safety issues. Our tool will be implemented using Java, SQL, and MySQL in Windows 10 operating system.

4. 研究创新点

For preliminary investigation, we conduct a pilot study of a drone which is used for multimodal mapping. The cyber physical architecture of this system consists of four subsystems: Ground Control System, Flight Control System, Onboard Computer and Sensor system [2]. For the convenience of analysis and presentation of the example, we simplify the system into a drone with following components: Global Positioning System(GPS), LiDAR, inertial measurement unit (IMU), RGB Camera, Flight Control System, Onboard Computer, and Ground Control Station.Component States PropertyRGB Camera off, on.idle, on.record frequency, resolution, frame rateLiDAR off, on.idle, on.record_detect intensity, round-trip-time, frequencyGPS off, on.idle, on.locate frequencyIMU off, on.idle, on.process speed, frequency, altitudeFlight Control System off, on.idle, on.move process frequency, communication frequency, speedOnboard Computer off, on.idle, on,process process frequency, communication frequencyGround Control Station off, on.idle, on.command communication frequencyTable2: States and properties of components The table above shows components, states and properties we generate manually from the requirements of the drone. Using ACTS (Advanced Combinatorial Testing Tool) uses IPOG algorithm to generate combinations, we generated 2-way combinations of above components and their states to identify the undesired states. Based on the CCM, we found that the rule: RGB Camera(on.record) ∧LiDAR(on.record_detect) ∧GPS(on.locate) ∧IMU(on.process) :Flight Control System(off) -> Flight Control System(on.move)is allowed here. However, when considering the communication frequency which is the property of RGB Camera, LiDAR, GPS, IMU and Flight Control System, we can find that the mismatch of these frequencies might result in an ONB. As a result, the drone might face a collision.