Daidalos Integration Framework TridentCom 2007
Download as PPT, PDF1 like620 views
The document outlines the DAIDALOS framework for testbed integration, detailing processes and innovations from multiple work packages (WPs) implemented through the Nidaros scenario. It describes integration challenges such as unstable network drivers, the complexity of the architecture, and successful testing outcomes on a mobile testbed. Key findings include improvements in mobile IP stability and collaboration among developers to meet integration deadlines.
More Related Content
Similar to Daidalos Integration Framework TridentCom 2007 (20)
More from Miguel Ponce de Leon @ TSSG / Waterford Institute of Technology (20)
Daidalos Integration Framework TridentCom 2007
- 1. Daidalos Framework for successful Testbed Integration Frances Cleary Grant Miguel Ponce de Leon TSSG – Waterford Institute of Technology Ireland
- 2. Daidalos WP5 Daidalos (49 partners), integration was an immense task co-ordinated and implemented by WP5. Steps leading to Integration Integration Tasks Defining Integration Processes and Models Defining conformance test Specifications Test Site Planning,Deployment and Integration Test planning/scheduling/status report documentation Test case execution, fault detection, result reporting.
- 3. Nidaros Scenario WP2 Innovations WP3 Innovations WP4 Innovations The Integration of WP innovations were completed through the selected ‘Nidaros’ Scenario.
- 4. Nidaros scenario Describe nidaros scenario
- 5. Daidalos WP5 Task Forces To evolve and implement this scenario, task forces were created Scene analysis Task Force (Input from all WP’s) Scene Step analysis Task Force (Input from WP5 step responsible) Mapping and Deployment Task Force
- 6. Daidalos Integration Model Due to the complexity of the Daidalos Architecture, the integration model addressed the following main areas Integrated Testbed (2 integrated test sites) Sophia Antopolis,France Aveiro, Portugal Integration-oriented developments Intra work package integration activities Formalisation of Integration roles and processes Identification of best Integration and Testing strategy (i.e. sandwich testing) Conformance Test Specification Identification of Nidaros specific WP interfaces Definition of Scenario specific Conformance tests Test Case Definition : Test Case Naming (e.g. N3:01), test summary, API’s & interfaces involved, initial conditions Test Report : Verdicts, person executed test, any closure actions and impacts, comments and possible actions to be performed if test fails.
- 7. Daidalos Testbed Daidalos Testbed Daidalos Physical Testbed Visualisation activities Validation activities and conclusions
- 9. For European based conferences the daidalos testbed was setup in a mobile Science Truck which demonstrated Daidalos Innovations. Daidalos Mobile Testbed
- 10. Daidalos Visualisation Virtualisation Tool (DLR) Figure 8 we have shown the layout for the CarPC view (a similar view was prepared for the PDA view) after some messages have been passed. It shows the simulated status of the network components and the messages from the major WP4 subsystems and third party services. The colour of the arrows indicates the presence of recent message traffic over these connections.
- 11. Daidalos Visualisation Lucent Virtualisation Tool
- 12. Daidalos Integration Testing Validation of the Nidaros Integrated Demonstrator conformance tests Sophia Antopolis in November 2005 , Aveiro in March 2006. The 1st validation could only produce very high-level results (i.e. pass/fail of TC). - Problems related to network layer, Mobile IP and WP2 network drivers which were unstable As issues were resolved we were able to validate the demonstrator at a much lower level of detail. Conformance session in Aveiro up to 120 test cases were planned, based on the Nidaros Test case specifications.
- 13. Integration Testing Example Test Case Bart is driving on the motorway, which triggers the launch of the Traffic information Service. Bart arrives at the airport, and continues to drive towards the car parking area of the airport. His car system screen shows the airport information carrousel. Information about all flights will be shown. Bart parks and leaves his car, taking his PDA with him. A transfer is invoked on the transferring components in the old service and starts the new service on PDA and stops the old service on CarPC. The airport arrivals information can now be seen on Barts PDA as he enters the airport arrival terminal.
- 14. Integration Issues Encountered Unstable MIPv6, switch from Mandrake to Ubuntu Machines crashing and rebooting became time consuming. Minor Errors encountered, led many times to major complications. Initial steps and configurations unforeseen eroded into valuable scheduled testing allocated time.
- 15. Conclusion and Results All tests performed on the test-bed successfully used Mobile IP, which remained very stable on Ubuntu in comparison to earlier attempts at using mobile IP on top of Mandrake. WP2 WLAN drivers were relatively stable compared to their earlier performance in Sophia. Route Optimisation worked over Mobile IP, with very noticeable performance improvements as compared to earlier tests on WP4 standalone test-beds. Registration module and several other components were dummy’s because of lack of integration on Ubuntu (previously worked under Mandrake). Communication was a main issue encountered during integration Key point - developers to meet iteration delivery deadlines Scenario step planning contributed positively to the integration process. The 1st successful integrated testing utilising all Work packages took place at Aveiro.
- 16. End Of Presentation Thank You For Your Time Contact details : Frances Cleary Grant, Miguel Ponce de Leon Organisation: TSSG , Waterford Institute Of Technology
Editor's Notes
- #3: With the Daidalos Architecture consisting of 3 technical work packages WP2 “ Network Integration” WP3 “Service and Network Management” WP4 “ Pervasive Systems” WP5 “Integrated System Evaluation” aim was to materialise the achievements of work packages into practical assessment to allow for concept validation.
- #4: With the Daidalos Architecture consisting of 3 technical work packages WP2 “ Network Integration” WP3 “Service and Network Management” WP4 “ Pervasive Systems” WP5 “Integrated System Evaluation” aim was to materialise the achievements of work packages into practical assessment to allow for concept validation.
- #5: Other task forces were also created as required , for example inventory control checkers task force.
- #6: With the Daidalos Architecture consisting of 3 technical work packages WP2 “ Network Integration” WP3 “Service and Network Management” WP4 “ Pervasive Systems” WP5 “Integrated System Evaluation” aim was to materialise the achievements of work packages into practical assessment to allow for concept validation.
- #8: Other task forces were also created as required , for example inventory control checkers task force.
- #11: Other task forces were also created as required , for example inventory control checkers task force.
- #12: Other task forces were also created as required , for example inventory control checkers task force.
- #13: The problems identified in 1st validation could only produce very high-level results (i.e. pass/fail of test cases). After these issues were resolved we were able to validate the demonstrator at a much lower level of detail, which has produced significant input to the technical work-packages Phase2. In a conformance session in Aveiro up to 120 test cases were planned based on the Nidaros Test case specifications. These covered the execution of multiple tests varying from step -1 to step 6 of the Nidaros scenario. Within in the first testing iteration 89 test cases were executed with 59 being successful.
- #14: Unstable Mobile IP hindered conformance testing initially in Sophia, this was rectified in the Aveiro test bed by switching from Mandrake to Debian-based Ubunto Linux. Specific machines crashing and rebooting proved to be very time consuming. Minor Errors encountered, led many times to major complications in the whole Daidalos system due to the large amount of Daidalos components and their interconnections. Undocumented initial steps and configurations unforeseen prior to the testing phase, eroded into valuable scheduled testing allocated time, as these required configurations and steps had to be figured out and setup correctly for the test case to be executed.
- #15: Unstable Mobile IP hindered conformance testing initially in Sophia, this was rectified in the Aveiro test bed by switching from Mandrake to Debian-based Ubunto Linux. Specific machines crashing and rebooting proved to be very time consuming. Minor Errors encountered, led many times to major complications in the whole Daidalos system due to the large amount of Daidalos components and their interconnections. Undocumented initial steps and configurations unforeseen prior to the testing phase, eroded into valuable scheduled testing allocated time, as these required configurations and steps had to be figured out and setup correctly for the test case to be executed.
- #16: Communication was one of the main issues encountered during Daidalos Phase I integration, In phase I the integration wiki was not as effective as it should have been. It can be a powerful tool if used effectively and would have great potential for Phase II. Following the change from Mandrake to Ubunto in Aveiro , MIPv6 became a lot more stable, and it was possible to complete further testing than was previously capable in Sophia Antipolis conformance iteration. A key point realised is the importance for developers to meet iteration delivery deadlines, leading to early fault detection. Scenario step planning contributed positively to the integration process. The First successful integrated testing utilising all Work packages took place at Aveiro, demonstrating overall successful interoperability and integration.