1 / 25

Overview of Embedded Software Research at USC

Overview of Embedded Software Research at USC. CSCI 599 – Software Engineering for Embedded Systems September 3, 2002. Events. Connectors. Components. Architectural Abstraction. Why Software Architecture?. Early, high-level system model Stakeholder understanding and communication

ash
Download Presentation

Overview of Embedded Software Research at USC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of EmbeddedSoftware Research at USC CSCI 599 – Software Engineering for Embedded Systems September 3, 2002

  2. Events Connectors Components Architectural Abstraction

  3. Why Software Architecture? • Early, high-level system model • Stakeholder understanding and communication • Focus on specific system properties • Separation of concerns • Early analysis and simulation • Tool-supported implementation • Improved processes and project management

  4. Architectural Style • Recurring structural, behavioral, and interaction patterns • Design vocabulary and grammar • Envelope of allowed change • Guarantee of desirable properties • Generalization from specific experience • Enables proper balance of • Intuition • Method • Theft

  5. Authorized User Authorized User Verify User Information Accept Login Event Window Opened Window Closed The C2 Architectural Style • Event-based communication among autonomous components, mediated by active connectors • Composition • No component-component links • Separation of computation from communication • Asynchronous, implicit invocationvia connectors • Substrate independence • Concurrency • Distribution • Heterogeneity User Repository Main Window Login Dialog Graphics Toolkit

  6. C a b q 1 a b q p p q a b c c Bj.bottom_in =  Cbi.top_out p q a b c i C B p q a b c 2 C 3 C2 Connectors • Enable key C2 properties • Implement message passing policies • Support message registration and filtering • Polymorphic interfaces Ci.bot = Ci.bot_in  Ci.bot_out Bj.top_out = f(Bj.bottom_in) Ci.top = Ci.top_in  Ci.top_out

  7. Programming-in-the-Small-and-Many – Prism

  8. Prism Challenges • Resource constraints • Demand highly efficient computation, communication, and memory footprint • Demand unorthodox solutions • e.g., off-loading components • Hardware and software heterogeneity • Proprietary operating systems • Dialects of programming languages • Device-specific data formats • Lack of support for inter-device interaction • Lack of support for code mobility

  9. Palm-3 Palm-2 PC Palm-1 iPAQ Prism Style • Directly leverages C2 • Peer-to-peer interactions • Side component ports, peer connectors, peer messages • Preserves substrate independence • Architectural self-awareness • Application level • Meta level • Admin component • Continuous analysis component • Messages • Application data • Component content • Architectural model • Subscription messages A Requests Notifications B C Peer D

  10. Prism Connectors • All Prism connectors are able to exchange data, code, and architectural models • Two communication paradigms • Client-server • Peer-to-peer • Four connector categories • Basic • Border • Secure • Multi-versioning

  11. Basic Connectors • Synchronous and asynchronous interaction • Message routing policies • Unicast • Multicast • Broadcast • Support for real-time constraints • Delivery guarantees

  12. Border Connectors • Spanning contexts • Address spaces • Processes • Machines • Marshalling and unmarshalling of information • XML encoding • Wireless interaction (IR) • Network link monitoring • Mechanisms • CORBA, RMI, Sockets, ILU, Q, Polylith

  13. Secure Connectors • Useful in connector-to-connector interaction • Reusable security module • E.g., used in IR border connector • Multiple such modules would allow altering security policy on the fly • Open issue • Mismatched security policies by interacting connectors

  14. Multi-Versioning Connectors • Ensure reliable component upgrades • Monitor multiple versions of a component • Correctness • Performance • Reliability • Functional behavior of system unaffected • Performance possibly affected • Possible impact on real-time systems • Special case – disconnected operation

  15. Support for Implementing Architectures • Software architectures provide powerful high-level concepts • components, connectors, events, configurations, constraints • Programming languages provide powerful low-level constructs • variables, arrays, pointers, procedures, objects • Bridging the two often is an art-form • Existing “middleware” technologies • support some architectural concepts (e.g., components, events) • but not others (e.g., connectors, topologies) • What is needed is “architectural middleware”

  16. Implementing Prism-Style Architectures – PrismMW • Extensible framework of abstract classes for Prism concepts • component, connector, communication port, message • implements interconnection rules and communication protocols • supports event monitoring and filtering • enables rapid construction of Prism-style applications • allows developers to focus on application-level issues • implemented in • Java JVM and KVM • Embedded Visual C++

  17. A B C D PrismMW Design Sizeunder 2KB atsystem start-up Performance300MHz PentiumII +Java KVM framework +two components +one connector +one thread +one million messages______________________________________________________________________________________________________~ 13 seconds Adjustable threading Adjustable scheduling

  18. Component Connector Component(name : String) Connector() Component() Connector(name : String) Component(name : String, junk : String) handle(r : Request) : void send(r : Request) : void handle(n : Notification) : void send(n : Notification) : void Architecture ConnectorThread ComponentThread Architecture() ConnectorThread(n : String) Architecture(name : String) ComponentThread() Architecture(name : String, n : int) ComponentThread(s : String) start() : void run() : void stop() : void shutdown() : void handle(r : Request) : void Message handle(n : Notification) : void addComponent(comp : Component) : void Message() addConnector(conn : Connector) : void Message(name : String) weld(conn : Connector, comp : Component) : void name() : String weld(comp : Component, conn : Connector) : void addParameter(parameterName : String, parameterValue : Object) : void weld(conn1 : Connector, conn2 : Connector) : void hasParameter(Name : String) : boolean removeComponent(comp : Component) : void removeParameter(Name : String) : void removeConnector(conn : Connector) : void getParameter(Name : String) : Object setThreadCount(n : int) : void getThreadCount() : int threadFunction() : void notifyArchitecture() : void Request Notification searchFIFO(f : SynchronizedFIFO, o : Object) : Object Request() Notification() Request(Name : String) Notification(Name : String) PrismMWAPI

  19. R Internal Working of Prism-MW Thread Pool Component A Component B handleRequest Connector C X R R N N R R 1 1 2 2 3 send Request Component D

  20. Example Prism Application

  21. Available Troops Repository Map Repository Admin Component Admin Component Map Display Map Display Admin Component Strategy Analyzer Troops Deployer Map Display M M Strategy Analyzer Admin Component Strategy Analyzer` Admin Component M Map Display Map Display M M M M M M M Another View of the Application M

  22. Leverages ComponentContent messages • Assumes preloading a skeleton configuration on each device • Implemented as an extension to Visio (COTS) Deployment Support – PrismDE add(DataRepository: source PC): PC weld(TopBorderConnector,C_IPAQAvailableTroops): iPAQ peerWeld(G_AvailableTroops,SideBorderConnector): Palm-1

  23. Support for Mobility • Component Content messages containing mobile code • Process • Possible detachment of the migrant component (using unweld and peerUnweld ) • Possible unloading of the migrant component (remove) • PC’s Admin Component - sends the migrant component • Receiving Border Connector(s) forward it to the local Admin Component whichreconstitutes the migrant component • Each Admin Component attaches the migrant component to the architecture(add, weld, and peerWeld)

  24. Support for Disconnected Operation • Minimize the risks associated with disconnection • Maximize availability / minimize degradation • Reroute communication • Fetch components before disconnection occurs • Relevant factors • Statefulness • Event frequencies across network links • Dependencies of candidate components • Type of disconnection • Time to disconnection • Required and available memory • Network bandwidth

  25. On-Going and Future Work • Message delivery guarantees • Decentralized ownership • Trust • Need for specialized programming languages • Resource analysis • Automated optimized application deployment • Scalability assessment

More Related