System Introspection for System Analysis on Mobile Devices

More documents

Recommendations

Info

3 RequirementsIn the context of this thesis the development of a system is described that canbe attached to the software of a robot <strong>for</strong> observation of running components,without influence on the normal behavior. This chapter describes the requirementsgiven <strong>for</strong> such a system. There are several elements to be distinguishedin this thesis:robotprobeclientdeveloperthe system to observe and to collect in<strong>for</strong>mationfromthe application attached to the robot software<strong>for</strong> observationthe application running on an external devicecommunicating with the probethe expert using the application to observe therobotWho is the Expert?In the context of this thesis an expert is the person developing the componentsof the robot. He extends existing components and adds new components to therobot. The expert combines all available components to make the robot behavein an autonomous way. He is not the end user interacting with the robot.The only interaction an expert does is <strong>for</strong> testing purpose of the componentsdeveloped.<strong>System</strong> Requirements of the DeveloperTo get an idea of the inner processes of the robot some requirements are givenby the developer.Requirement 1:Only present in<strong>for</strong>mation requested and filter them to the importantparts with a human readable frequencyWhen observing a component on the robot, the in<strong>for</strong>mation available can bequiet complex and offers more detail then needed. The data is often presented9
with a very high frequency which makes it hard <strong>for</strong> a human to observe acomponent of the robot.Requirement 2:Send and receive in<strong>for</strong>mation with minimized delayThe delay between the data send and the time of receiving it on the clientmust be minimized. A high delay can make the data obsolete which makes adecision on the robots state dispensable.Requirement 3:Change component views at any timeOften the expert wants to check other components on the run, to make surechanges on one component do not influence other components.Requirement 4:Cooperative work without influencing other observersOften more then one expert is working with the system. Every expert needs hisown view onto the components without interfering other experts. A multi-userenvironment is there<strong>for</strong>e beneficial.Requirement 5:Control logging of filtered in<strong>for</strong>mation on command and create uniquelogging filesMany components already create logging files that can be analyzed when therobot has ended its current per<strong>for</strong>mance. These files are written once percomponent and must be aligned by the developer himself. Also the componentslog their data when the robot starts until it has stopped working. For a posthocanalysis the probe must collect and filter in<strong>for</strong>mation from componentsselected by the developer. The developer must be able to initiate the processand stop it on command. All collected data must be saved into a single file <strong>for</strong>each developer.Requirement 6:Extension must be possibleDue to the changes of the components of the robot, extension of the systemmust be possible. New components must be easily attached to the system.Requirement 7:Establish a wireless connection to the probeDue to the need that the robot acts in an autonomous way, the expert does notwant to move towards the robot <strong>for</strong> observation of components. The connection10
Page 1: Bringing System <s
Page 5 and 6: AbstractSystem <st
Page 7 and 8: output, so each component is offeri
Page 9 and 10: of the system and the decisions mad
Page 11 and 12: created a telelaboratory where two
Page 13: Like the telelaboratory there is a
Page 17 and 18: Due to improving technology the use
Page 19 and 20: Figure 4.1: ToBI platfor</s
Page 21 and 22: Figure 4.3: The architecture behind
Page 23 and 24: Figure 4.5: Typical instant messagi
Page 25 and 26: 5 System DesignThe
Page 27 and 28: Figure 5.2: Message exchange betwee
Page 29 and 30: Figure 5.4: Beacon running between
Page 31 and 32: Figure 5.5: Reading and processing
Page 33 and 34: data and only forw
Page 35 and 36: For example a developer can select
Page 37 and 38: Figure 5.13: Principle of tabbed na
Page 39 and 40: 6.1 The Communication InterfaceThe
Page 41 and 42: 6.2 The Probe - Implementation of t
Page 43 and 44: stop all active processes of the co
Page 45 and 46: is received containing the TAG of t
Page 47 and 48: The selected sensors give a good im
Page 49 and 50: 1 2 4 6 8 Listing 6.2: Example of t
Page 51 and 52: TabConfig - The Status ViewThe TabC
Page 53 and 54: Each view adds a listener to the co
Page 55 and 56: LoginController which also observes
Page 57 and 58: tends the JPanel class. The templat
Page 59 and 60: 7 EvaluationIn the previous chapter
Page 61 and 62: Name Description CharactersSingleli
Page 63 and 64: Figure 7.1: Latency of receiving da
Page 65 and 66:
For this thesis only a rough estima
Page 67 and 68:
Laptop CPU load without Probe CPU l
Page 69 and 70:
8 ConclusionsIn the context of this
Page 71 and 72:
9 OutlookGiven this new tool its no
Page 74:
BibliographyBurrell, A. and A. Soda
Page 77 and 78:
6.10 Main classes of the Java clien
Page 79 and 80:
AppendixUse CasesUse Case 1: Connec
Page 81 and 82:
Use Case 4: Disconnect from compone
Page 83 and 84:
Use Case 9: Sending beacon to keep
Page 85 and 86:
Figure 9.4: Latency of receiving da
show all

System Introspection for System Analysis on Mobile Devices

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?