OSGi: Best Tool In Your Embedded Systems Toolbox

2,457 views

Published on

We discuss several of our past and current OSGi-based solutions for defense systems, mining equipment, construction equipment, industrial automation, and automotive/telematics domains. We present some best practices for building flexible, cross-platform, high-performance embedded application and the resulting lessons learned along the way. We demonstrate how the Eclipse Runtime Components and Frameworks can be used to access communication buses such as CAN, J1939, J1850, and MIL-STD-1553. Finally, we explain how using OSGi and Equinox can simplify the development, testing, and deployment of your next application, whether embedded or not.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,457
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
67
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

OSGi: Best Tool In Your Embedded Systems Toolbox

  1. 1. OSGi: The Best Tool in Your Embedded Systems Toolbox OSGi DevCon Europe 2009 Brett Hackleman & James Branigan Copyright © 2009 Band XI International, LLC
  2. 2. Introduction <ul><li>OSGi has been an open standard for over a decade </li></ul><ul><li>Original domain (home gateways) has yet to take off </li></ul><ul><li>Instead, OSGi has gained significant traction as a well-designed software componentization and deployment framework </li></ul><ul><ul><li>Eclipse, as the base platform </li></ul></ul><ul><ul><li>J2EE server providers (Server-side OSGi) </li></ul></ul><ul><ul><li>Telecommunications (Sprint Titan) </li></ul></ul><ul><ul><li>Embedded (MicroDoc & Band XI) </li></ul></ul>
  3. 3. Our Perspective: A Decade of Embedded OSGi <ul><li>Automotive, Fleet Management, Remote Monitoring </li></ul><ul><ul><li>OnStar scenarios, diagnostics, infotainment, hands-free, navigation </li></ul></ul><ul><li>Industrial Controls, RFID </li></ul><ul><ul><li>Sensors, scaling, configuration management, deployment </li></ul></ul><ul><li>National Guard: WMD Sensors, Situational Awareness </li></ul><ul><ul><li>Provisioning new apps, biometric sensors, P2P comms </li></ul></ul><ul><li>Army: Vehicle Diagnostics & Prognostics Architecture </li></ul><ul><ul><li>Provisioning new algorithms, flexible UI, provisioning </li></ul></ul><ul><li>Mining Equipment: Diagnostics, Machine Control </li></ul><ul><ul><li>Rapid turnaround on new applications, flexible architecture </li></ul></ul>
  4. 4. Challenges of Embedded Systems <ul><li>Platforms </li></ul><ul><ul><li>Availability, variability, scarcity, stability, cost (future of Java?) </li></ul></ul><ul><li>Peripheral hardware: sensors and actuators </li></ul><ul><ul><li>Availability, scarcity, size, cost </li></ul></ul><ul><li>User interfaces </li></ul><ul><ul><li>Input methods, desktop vs. appliance </li></ul></ul><ul><li>Constraints </li></ul><ul><ul><li>“ Realtime”, memory/CPU limitations, development vs runtime costs </li></ul></ul><ul><li>Applications </li></ul><ul><ul><li>Yes, you still have to write the application(s) too! </li></ul></ul>
  5. 5. Accepting the Challenge <ul><li>Lots of Risk == More Fun! </li></ul><ul><li>Tackle risks head-on </li></ul><ul><ul><li>Build simulators, identify alternate paths and representative systems </li></ul></ul><ul><li>Embrace change </li></ul><ul><ul><li>Agile development methodologies build change into the process </li></ul></ul><ul><li>Use agile methods, frameworks, and tools </li></ul><ul><ul><li>Testing frameworks (JUnit, FitNesse) </li></ul></ul><ul><ul><li>Continuous integration build systems (Jazz) </li></ul></ul><ul><ul><li>Software Configuration Management (Jazz) </li></ul></ul><ul><ul><li>And, of course… </li></ul></ul>
  6. 6. OSGi – Highly Cohesive, Loosely Coupled Component Model <ul><li>Strong component model , common language </li></ul><ul><li>Forces best practices from day one </li></ul><ul><li>Core specification is pure and simple </li></ul><ul><li>Logical and clear mapping with whiteboard drawings </li></ul><ul><li>Dynamic life-cycle allows install/unintall/update without restart </li></ul><ul><li>Integrated and sophisticated deployment mechanism </li></ul><ul><li>Isolation of external libraries to monitor and consume capabilities </li></ul><ul><li>Discourages spaghetti code : bundle partitions are like firebreaks </li></ul><ul><li>Discourages code rot : containment lowers barrier to refactoring </li></ul>
  7. 7. Vehicle Bus Control: DeviceKit Support of J1939 Protocols <ul><li>J1939-21: Datalink </li></ul><ul><ul><li>Basic Protocol Data Unit (PDU), PGNs, priorities, etc. </li></ul></ul><ul><ul><li>Transport Protocol (multi-packet, broadcast and point to point) </li></ul></ul><ul><li>J1939-81: Network Management </li></ul><ul><ul><li>Address Claim (fixed, arbitrary address) </li></ul></ul><ul><ul><li>Discovery </li></ul></ul><ul><li>J1939-73: Diagnostic Messages </li></ul><ul><ul><li>DM1: Active Diagnostic Trouble Codes (DTCs) </li></ul></ul><ul><ul><li>DM2: Logged DTCs </li></ul></ul><ul><ul><li>DM14/15/16: Memory Configuration </li></ul></ul><ul><ul><li>Additional information for active/logged DTCs </li></ul></ul><ul><li>Proprietary J1939 Messages </li></ul><ul><ul><li>For solution-specific ECU’s </li></ul></ul>
  8. 8. In Vehicle J1939 Device Software Stack CAN BUS CAN Connection J1939 Transport J1939 Diagnostics DTC Lamp Status J1939 Message J1939 Address Claim Data Transfer Record JP CAN Peak CAN Fake CAN
  9. 9. J1939 (CAN) Test Bench Gryphon Ethernet to J1939 Protocol Bridge DPA III RS232 to J1939 Protocol Bridge J1939 2-wire CAN bus J1939 Sensors Caterpillar A5 M2 ECU Embedded Platform w/CAN tranceiver DT3000 (Windows) Eurotech Zeus (Linux) Wachendorff A5 (Linux)
  10. 10. J1939 Interfaces Supported <ul><li>Dearborn Group Gryphon (Ethernet to CAN) </li></ul><ul><li>Peak CAN (USB to CAN) </li></ul><ul><li>Wachendorff on-board PCAN transceiver </li></ul><ul><li>Eurotech Zeus on-board CAN transceiver </li></ul><ul><li>DriverTech DT-3000A </li></ul><ul><li>DRS TEM BlueRing Platform </li></ul><ul><li>RP1210A library (CAN/J1939 on Windows, Cat CMPD) </li></ul>
  11. 11. Industrial Graphics Framework <ul><li>Desktop metaphors do not work in industrial control settings </li></ul><ul><li>Funded by US Army under Small Business Innovation Research (SBIR) Grant </li></ul><ul><li>Designed for touchscreen and hard-/soft-button navigation </li></ul><ul><li>Set of custom SWT widgets and exemplary sample applications </li></ul><ul><li>Includes application shell, menu bar, graphics oriented widgets, and pop-ups </li></ul>
  12. 12. Cyrano™ Overview ACAA  MultiRAE  AreaRAE  Thermo FH40  Identifinder Gamma Spec HAZMAT ID VDR 2 VDR 13 Barcode/RFID Scanner Sample Collection Hazard Detection SCBA Tank  Pulse Oximeter Heart Rate & BP Monitor  Others… CAN  J1939  J1850  OBD II Others… Health Status Monitoring Vehicle Mounted Systems for Status Monitoring  WIFI Network Location Tracking  Decision Support; Command and Control  Sensor Fusion  Mapping Services  Software Updates  Voice Over IP Comms  Multicast to Other Units  Existing WMD CST CBRN Sensors Wireless Digital Media Remote Expert Input  Biometrics Vehicle Diagnostics GPS Joint Operation Command Sensor Fusion System ™
  13. 13. Industrial, Mining, Construction, & Military Applications <ul><li>Building field production applications for mining and construction machines </li></ul><ul><ul><li>Salt Harvester </li></ul></ul><ul><ul><li>Foundation Drill </li></ul></ul><ul><ul><li>Train Engines </li></ul></ul><ul><li>Proves viability of the architecture and implementation in fielded environments </li></ul>
  14. 14. Mining & Construction Systems: Goals & Challenges <ul><li>Goals </li></ul><ul><ul><li>Shorten Application Development Time from 6-9 months to 2 weeks! </li></ul></ul><ul><ul><li>Tackle this in stages by building and refining the foundation </li></ul></ul><ul><ul><ul><li>1st application: Duplicate existing reference application (6 months) </li></ul></ul></ul><ul><ul><ul><li>2nd application: Salt Harvesting Machine (10 weeks) </li></ul></ul></ul><ul><ul><ul><li>3rd application: Foundation Drill Machine (5 weeks) </li></ul></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>2 platforms to be supported: one legacy, one newly selected </li></ul></ul><ul><ul><ul><li>Legacy platform: 400MHz ARM, 32MB RAM/ROM, WindowsCE </li></ul></ul></ul><ul><ul><ul><li>New Platform: 400MHz PPC, 1GB RAM, 64MB ROM, Linux </li></ul></ul></ul><ul><ul><li>Machinery does not exist yet; we will never touch it </li></ul></ul><ul><ul><li>Incumbent native application to be displaced </li></ul></ul>
  15. 15. Challenge #1: New Platform Integration <ul><li>Risks at Development Start </li></ul><ul><ul><li>Platform not available until late in project schedule </li></ul></ul><ul><ul><li>SWT not running on the platform </li></ul></ul><ul><ul><li>CAN native JNI libraries did not exist </li></ul></ul><ul><li>Coping Strategy to Get Started </li></ul><ul><ul><li>Started development with similar Linux platform </li></ul></ul><ul><ul><li>Used Gryphon (Ethernet-to-CAN) transport bundles </li></ul></ul><ul><ul><li>Found a CAN transport supported by same driver (PCAN-USB) </li></ul></ul><ul><ul><li>Built native JNI libraries and bundles to access CAN bus </li></ul></ul><ul><li>When Platform Became Available </li></ul><ul><ul><li>Validated JNI libraries and bundles against platform CAN transceiver </li></ul></ul><ul><ul><li>Ran application headless while SWT in development </li></ul></ul><ul><ul><li>Ran entire application once SWT had been ported </li></ul></ul>
  16. 16. Challenge #2: Salt Harvesting Controls (Sensors & Actuators) <ul><li>Risks at Development Start </li></ul><ul><ul><li>Custom machine that was still in design and development </li></ul></ul><ul><ul><li>Assembled on-site in Australia, half way around the world, remote </li></ul></ul><ul><ul><li>Limited testbench testing time available </li></ul></ul><ul><li>Coping Strategy to Get Started </li></ul><ul><ul><li>Agreed on logical messages and application screen layour and flow </li></ul></ul><ul><ul><li>Built HTTP based simulator (self hosted) </li></ul></ul><ul><ul><li>Agreed on J1939 message specs: mix of standard and proprietary </li></ul></ul><ul><ul><li>Encoded as DeviceKit ML, built Device bundles </li></ul></ul><ul><ul><li>Ran against real ECU via Gryphon gateway from development box </li></ul></ul><ul><li>When Platform Became Available </li></ul><ul><ul><li>Ran same stack on target platform </li></ul></ul><ul><ul><li>Swapped in target platform CAN transceiver bundles </li></ul></ul><ul><ul><li>Created HTTP based publisher </li></ul></ul><ul><ul><ul><li>Simulated ECU and advanced scenarios over real CAN link </li></ul></ul></ul>
  17. 17. Best Practices for Embedded OSGi (or any OSGi effort) <ul><li>Use Eclipse PDE and p2 tooling - bundles are first class citizens! </li></ul><ul><li>Identify target platform early, put under version control </li></ul><ul><li>Use only Import-Package and Export-Package for visibility </li></ul><ul><li>Use Declarative Services to manage optional and required services </li></ul><ul><li>Separate interfaces from implementation </li></ul><ul><li>Separate application logic implementation from OSGi specific code </li></ul><ul><li>Build fake, simulated, and real devices to keep moving </li></ul><ul><li>Keep application work off OSGi threads (activation or call-backs) </li></ul><ul><li>Assume nothing about start order </li></ul><ul><li>Test shutdown behavior obsessively to expose loose ends </li></ul><ul><li>Have at least one OSGi expert on your team </li></ul><ul><li>Develop using OSGi – even if it will not be used in final product </li></ul>
  18. 18. Open for Discussion <ul><li>Questions? </li></ul><ul><li>Comments? </li></ul>

×