1. Merlin ITEA Symposium 2006

2. 2006Merlin Overview2 Problem domain Companies hardly develop embedded products completely on their own Embedded systems need to be developed: –globally distributed –in collaboration with subcontractors, third party developers and in-house development –using the advantages of collaboration, solving the disadvantages Embedded systems industry still growing –Embedded systems more dominant in all markets –Increasingly demanding requirements Development technologies insufficiently prepared for different collaboration modes

3. 2006Merlin Overview3 Consortium Finland: –Nokia Application partner –Solid Application partner (SME) –Oulu University Technology partner –VTT Technology and exploitation partner –Incode Application partner (SME) Netherlands: –Philips Technology and application partner –LogicaCMG Application and exploitation partner –Delft University Technology partner Sweden: –Sony Ericsson Technology and application partner –Ericsson Technology and application partner –Lund University Technology partner

4. 2006Merlin Overview4 What does Merlin Project do? Enabling the collaborative development of embedded systems with multiple partners Emphasising the advantages of collaborative development and neutralising the disadvantages of collaboration Developing dedicated effective and efficient processes and technologies for collaboration Increasing deployability by initiating industrial cases to validate Merlin solutions Enhance project results into exploitable solutions for collaborative development

5. 2006Merlin Overview5 Scenario Symposium 2006

6. 2006Merlin Overview6 Work packages Work package 1: Collaboration Enablers activities for collaborative embedded product development; concepts and tool-chains for inter-organisational collaboration, such as partnering, open source-based co-operation Work package 2: Non-functional Demands activities for non-functional (quality) aspects of embedded systems development. Modelling and validation of non- functional aspects for collaborative product development with a focus on requirement engineering and architecting Work package 3: Advanced coding and testing activities for embedded system software implementation. Modelling, implementation, code-generation and testing for embedded system components in a collaborative context. Work package 4: Exploitation activities for project exploitation. Focus on standardisation, dissemination, marketing and experience exchange. Especially exploitation and standardisation are its main focus

7. 2006Merlin Overview7 Solution status for problems (year 2005) Lack of interface management Lack of common understanding of architecture Lack of integration strategy and plan Lack of knowledge and skills in integration team Underestimated integration effort and time Integration responsibilities not clearly assigned Status of test results not shared Sharing of same test environment not feasible Integration not centrally controlled Lack of skills for multiple team CM Problems not reproducible Uncontrolled releases Lack of library system enabling multi-team CM Acceptance procedures of mutual deliveries not defined Need for explicit communication underestimated Underestimated learning curve Escalation mechanisms not defined Suppliers not or not timely audited Lack of stated criteria for selecting suppliers Confidentiality No detailed plan or clear agreements with suppliers Not defined change management procedures Lack of leveling of local and global change requests and problem reports Underestimated impact of changes to other parties work Lack of involvement of right people in requirements and architecture analysis and validation No common understanding about the requirements Diverse RM practices between collaboration parties Dependencies between teams not made explicit and managed Unstable requirements Not defined prioritization rules and practices of the requirements in case of many interest groups Not defined practices for resolution of conflicting requirements No solution yetIdeaAvailableProven No traceability of requirements in collaborative development No transparency of the collaborative engineering chain Consistency between engineering tasks not manageable No visibility of collaborative development status beyond partner borders Not traceable whether the product meets the requirements in collaborative development Sharing and maintaining the integration and testing knowledge effectively Sharing resources efficiently, managing access, traceability and privacy Solution status for problems (current)

8. 2006Merlin Overview8 Merlin tool

9. 2006Merlin Overview9 Tool chain architecture Requirements mgmt tool Requirements mgmt tool Configuration mgmt tool Configuration mgmt tool Testing tool Requirements Design Implementation Testing Integration Eclipse Requirements Management view Requirements Management view Configuration Management view Configuration Management view Testing view Testing view Project Mgmt tool Project Mgmt tool Project Management view Project Management view Improved traceability Eclipse-based Merlin tool

10. 2006Merlin Overview10 Outlook to Merlin tool chain

11. 2006Merlin Overview11 Current cases vs handbook topics Management practices –Collaboration strategy –Contracts –Collaboration management –Project management –Risk management –Information management Engineering practices –Requirements development –Requirements management –Architecture design –Software design –Software implementation –Integration –Testing –Release Support practices –Configuration management –Quality assurance –Documentation –Improvement process –Human resource management –Infrastructure –Co-operative work Cases often contribute to more topics, this mapping depicts the main topic addresses.

12. Thank you for your attention and See you next year! ITEA Symposium 2006