Modeling Space Data Systems Architectures 6 Nov 2008 Peter Shames

1. Modeling Space Data Systems Architectures 6 Nov 2008 Peter Shames NASA Jet Propulsion Laboratory, California Institute of Technology

2. Topics • Why views of system architectures? • Challenges of space system architectures • Existing terrestrial approaches must be adapted for space • Need a common architecture methodology and information model • Need appropriate set of viewpoints for the space domain • Reference Architecture for Space Data Systems (RASDS) • Description of set of viewpoints • Extension into Space Systems in general • Examples of use • Relationship to other methods • DoDAF and others • SysML • Adding RASDS viewpoints to SysML JPL Modelling Early Adopters (MEA)

3. What is System Architecture and … • System architectures are complex, multi-faceted things • Hardware structures • Software elements • Functional composition • Control and data flows • Environment and interactions • Organizational interfaces & contracts • End-to-end communications paths • Science, user, & operator interfaces • And don’t forget the interactions among these, electrical, power, thermal, dynamic, etc, etc • Where do you “stand” to get a view of all this? JPL Modelling Early Adopters (MEA)

4. … why Views? • As with any programming or system engineering activity … • Breaking a problem into pieces makes it more manageable • Smaller pieces are easier to work with • Logical coherence within a “piece” better supports reasoning about behavior and properties • Views are perspectives on an architecture, intended to give us useful leverage in understanding and analyzing the system • But, we need to be clear about what is represented in any given viewpoint, and • We also need to model the relationships among the elements shown in different views … • A structural element may also act as an electrical ground plane and a thermal shield • So how to we arrive at a useful set of views and … • How does this relate to the current methods that are in vogue, I.e. SysML and DoDAF? JPL Modelling Early Adopters (MEA)

5. Architecting and Engineering Space Systems is Hard • Many Stakeholders • Organizations (NASA, international partners, contractors) • Competing requirements (cost, schedule, risk, science, technology, survivability, maintainability, buildability) • Many different system aspects • Logical (functionality, information, control) • Physical (hardware, software, environment) • Interoperability and cross support • Science & operational capabilities • Autonomous and human mediated operations • Long and complex system (of systems) lifecycle • Development phases • Requirements, design, implement, I&T, V&V • Operations and sustaining • Cradle to grave lifecycle • Mission view vs infrastructure view …motion JPL Modelling Early Adopters (MEA)

6. System Architecture Model Objectives • Provide clear & unambiguous views of the design • Show relationship of design to requirements and driving scenarios • Separate design concerns in the model to maintain degrees of freedom to do trades • Detail the model & views to the level appropriate for further systems engineering, support evolving design • Enable concurrent design of spacecraft, ground systems, science operations, control systems, and components • Establish system engineering (SE) controls over the allocations and interfaces • Provide executable models of the interactions (future) Even document driven design processes benefit from clear presentation of architectural elements and design. Required tool capabilities and MBE elements shown like this. JPL Modelling Early Adopters (MEA)

7. Existing System Architecture Methods Inadequate for Space • Existing methods tacitly assume modeled objects are fixed in space and are usually in continuous and instantaneous communication • DoDAF, RM-ODP, TOGAF, Zachman, Krutchen 4+1, … • Space systems tend to violate these assumptions • Therefore, any of these modeling methodologies must be adapted to describe space systems • Viewpoints must accommodate complex logical and physical interactions • UML, SysML provide design diagrams, but do not directly support the necessary viewpoints • DoDAF has only three “views” and is intended to support system acquisition, not really design JPL Modelling Early Adopters (MEA)

8. RM-ODP & RASDS Characteristics • The specification of a complete system in terms of viewpoints. • The use of a common object model for the specification of the system from every viewpoint. • The use of views to tailor user or domain specific analyses of the system. • The definition of a modeling infrastructure that provides support services for system applications, hiding the complexity and problems of defining mission specific models. • The definition of a set of common transformation functions that provide general services needed during the design and development of space systems. • A framework for the evaluation of conformance of models and designs based on conformance points. JPL Modelling Early Adopters (MEA)

9. Business Concerns Organizational perspective Enterprise Physical Concerns Node & Link perspective Connectivity Computational Concerns Functional composition Functional Data Concerns Relationships and transformations Information Protocol Concerns Communications stack perspective Communications Space Data System Several Architectural Viewpoints Derived from: RM-ODP, ISO 10746 Largely compliant with IEEE 1471-2000 JPL Modelling Early Adopters (MEA)

10. Engineering Viewpoint • System Design & Construction • Functional allocation • Distribution of functions and trade-offs • Development • Validation & verification • Augment to Capture: • Mission Design & Drivers • Requirements • Cost • Enterprise Risks • Based on RMODP** • Augment to Capture: • Structure • Power • Mass • Thermal • Orbit • Propulsion Extended by: MBED Project, Shames & Skipper RASDS Semantic Information Model Derivation Process RASDS as Architectural Framework * • EnterpriseViewpoint • Organizations • People • Use Case-Scenarios • Contracts/Agreements • Connectivity Viewpoint • Connectivity • Components & connectors • Physics of Motion • End to End View • External Forces • Performance • Functional Viewpoint • Functional Structure • Functional Behavior & interfaces • End to End View • Cross Support Service • Information Viewpoint • Information & information management • Scenarios • End to End View • Communications Viewpoint • Protocols & comm standards • End to end Information Transfer Mechanisms • Cross Support Services * Reference Architecture for Space Data Systems (RASDS) ** Reference Model Open Distributed Processing (RMODP, ISO 10746 spec) JPL Modelling Early Adopters (MEA)

11. Perspective (Viewpoint) • Defines Objects • Defines Relations • Defines Rules • Exposes Concerns RASDSTop Level Object Ontology Composed Of Organization • Mission • Requirements • Objectives FulfilledBy • Goals • Scenarios ComposedOf Owns/Operates Fulfills Calls Function Information Produces Consumes • Logical structure • Data • Behavior • Metadata IsAllocatedTo • Interfaces ComposedOf • Rules • Constraints ContainsInstances Node Environment ProvidesService Affects Uses • Type ImplementedOn • Attributes ConnectVia • Physical Environs Communication • Ports • Attributes • Location ConnectToPort • Protocol stack Link AssociatedWith • Standards • Type • Attributes JPL Modelling Early Adopters (MEA)

12. Space Data System Architectural Notation Object Object with Interface Object Encapsulation Management Node Encapsulation (physical aggregation) Node (physical location) Service External Concerns Logical Link Physical Link Space Link (rf or optical) JPL Modelling Early Adopters (MEA)

13. Mars Exploration Program Example Enterprise View Instr S Mars Exploration Program Federation MEx Proj MSL Proj ExoMars Prog DSMS MRO Proj MMO Prog S Service Z MRO Ops Instrument Integration Cross- Support Agreements Science PI Org NASA/ JPL Tracking Agreements ICDs Operations Agreements ESA Enterprise Concerns: Requirements Objectives Roles Policies Activities Configuration Contracts / agreements Lifecycle / Phases S/C Contractor JPL Modelling Early Adopters (MEA)

14. Monitor & Control Directive Generation Directive Management Directive Execution Mission Planning Data Repository Data Acquisition Mission Analysis LT Data Repository Orbit Determ Spacecraft Analysis Radiometric Data Collect Tracking Functional ViewExample Functional Objects & Interactions • Functional Concerns: • Behaviors • Interactions • Interfaces • Constraints JPL Modelling Early Adopters (MEA)

15. Command & Data Handling Computer Spacecraft Transceiver S/C Bus Science Instrument ACS Computer Connectivity ViewNodes & Links SPACECRAFT Mission Planning Computer Internet Space Link Ground Tracking Station Spacecraft Control Computer • Connectivity Concerns: • Distribution • Communication • Physical Environment • Behaviors • Constraints • Configuration JPL Modelling Early Adopters (MEA)

16. Science Spacecraft Science Institute Monitor & Control Directive Execution Radiometric Data Collect Attitude Control LT Data Repository (Archive) Mission Planning Data Acquisition Data Repository Comm Mgmt Directive Generation Data Repository Tracking Directive Generation Data Repository Directive Management Monitor & Control Tracking Comm Mgmt Mission Analysis Spacecraft Analysis Orbit Determ Traj Design Radiometric Data Collect Tracking Station S/C Control Center Connectivity ViewMapping Functional Elements to Nodes • Allocation View: • Implemented Functions • End to End Behavior • Performance • Throughput • Trade studies JPL Modelling Early Adopters (MEA)

17. Communications Viewpoint Protocol ObjectsEnd-To-End Command Processing GROUND SYSTEM SPACECRAFT Payload Commands Command Generation Command Execution C&DH Packet Packet Packet (Relay) Packet Tracking Station TC Space Data Link TC Space Data Link (Relay) TC Space Data Link Frame SLE CLTU SLE CLTU • Communications Concerns: • Standards • Interfaces • Protocols • Technology • Interoperability • Suitability TCP/IP TCP/IP TCP/IP TCP/IP PPP RF Generation PPP RF Generation Onboard Physical Onboard Physical JPL Modelling Early Adopters (MEA)

18. MSL End-End Network ArchitectureExample Connectivity Overview MSL Planning and Control Center MSL Rover Rover Command Generation C&DH SSR Payload MRO Spacecraft File Xfer Instr Command Execution Rover Command Execution Relay Electra Large SSR MRO Control Center Relay Command Execution File Handling Electra - lite C&DH File Mgmt Cmnd File Processing Relay Command Generation In-situ delivery In-situ Delivery Space Link Processing Cmnd Integ DSN Proximate Link SDST File Prep Space Data Link Delivery Link Prep XMTR Deep Space Link Performance Overlay Processor speed CPU requirements Link capacities Throughput Storage capacities Team Overlay MSL MRO DSMS Contractor Data Flow Overlay Uplink Downlink Relaying JPL Modelling Early Adopters (MEA)

19. Relationship to Other Methods • Comparison table of architecture methods • RASDS, RM-ODP, DoDAF, Krutchen, Zachman • Brief discussion of DoDAF • DoDAF & RASDS Elements • DoDAF Products & RASDS Views (more in backup) • SysML adaptation for system architecture • Diagram types and views • Mapping to RASDS JPL Modelling Early Adopters (MEA)

20. Comparison of Architecture Methods Derived from: Maier, ANSI/IEEE 1471 and System Engineering JPL Modelling Early Adopters (MEA)

21. DoDAF (Notional) RASDS (Notional) Performs EnterpriseObject FunctionalObject Operational Activity Performs Operational Node Hosts Owns Is implemented by Interacts over Owns “RAS-DAF” Node Connects Link System Function System Node Hosts Performs Ent Obj / Ops Node FunctionalObject Operational Activity Performs Hosts Owns Is implemented by Interacts over Generates or consumes Is exchanged over Generates or consumes InformationObject System Function Hosts Is exchanged between (System) Node Connects Link System Data Implemented by Is exchanged between Generates or consumes Is exchanged over Generates or consumes System Data Protocols InformationObject

22. SysML Diagram Types Source: SysML Partners JPL Modelling Early Adopters (MEA)

23. Mapping RASDS into SysML • No simple one for one mapping • RASDS uses Viewpoints to expose different concerns of a single system • SysML uses specific diagrams to capture system structure, behavior, parameters and requirements • Several SysML diagrams, focused on different object classes, may be usefully applied to any given RASDS Viewpoint • Extended SysML Views may be used to define the relationships between Viewpoints and Diagrams • SysML methods & tools can support more accurate fine grained modeling of structure, relationships and behavior than was expected of RASDS • But, SysML needs to be adapted, via a profile or some other method, to guide use of appropriate views JPL Modelling Early Adopters (MEA)

24. Mapping RASDS into SysML • Enterprise • Organizational structure & behavior diagrams • Use case, activity, and sequence diagrams • Requirements & constraints for rules, policies & agreements • Connectivity • Physical structure, composition, behavior & class diagrams • Parametric diagram for physical link & environment characterization • Functional • Logical structure, behavior & class diagrams • Activity, state chart, parametric, & timing diagrams • Informational • Information class & parametric diagrams • Communication • Protocol structure & behavior diagrams • State machine, sequence, activity & timing diagrams JPL Modelling Early Adopters (MEA)

25. Enterprise View Using SysML Use Case Diagram <<usage>> Enterprise: Use Case Mars Exploration Program Federation <<includes>> <<includes>> Agency ABC Agency QRS Cross Support Agreement <<extends>> <<extends>> <<includes>> <<includes>> Science Team <<primary>> <<includes>> Mission Q Science Team <<primary>> Mission A GTN B <<includes>> <<extends>> Relay Service A Instr C <<extends>> Mission Operations Team <<Primary>> TT&C Service B Instrument Team <<Secondary>> Service Operations Team <<Secondary>> Instrument Integration Operations Contract JPL Modelling Early Adopters (MEA)

26. Connectivity View (Nodes & Links) Using SysML Components (Spacecraft) Spacecraft CDH : CmdDataHandlingSystem sciInstr : scienceInstrument ap: Mechanical s : Sensor dm : DataManager SensorData DataDonePort CmndIn Port ecu : Execution Control Unit ap : Aperture InstrCmnd Port ObsFin Port oc : ic : ObsControl InstrControl TakeObs TelemPort dl : DownLink TeleCmndPort ul : UpLink Derived from: SysML Partners RFAntenna JPL Modelling Early Adopters (MEA)

27. dl : DownLink ul : UpLink Connectivity View (Nodes & Links) Using SysML Components (MOS & TT&C Systems) MOS : MissionOpsSystem TT&C : TrackTelemCommand DL Port Telem Port TM : Telemetry dm : DataManager TelemData Tele Cmnd Port Re Trans Port RF Ant UL Port TelemDonePort ObsReq Port TC : MOP : Mission Telecommand OpsPlanning CmndData Cmnd Port SC : SendCmnd Pt : Pointing Ant: Mechanical PointingData JPL Modelling Early Adopters (MEA)

28. Spacecraft CDH : CmdDataHandlingSystem sciInstr : scienceInstrument AP: Mechanical S : Sensor dm : DataManager SensorData DataDone Port Cmndin Port ecu : Execution Control Unit Ap : Aperture InstrCmnd Port ObsFin Port MOS : MissionOpsSystem TT&C : TrackTelemCommand oc : IC : ObsControl InstrControl Take Obs DL Port Telem Port TM : Telemetry dm : TelemPort dl : DownLink DataManager TelemData TeleCmndPort Tele Cmnd Port RFAnt ul : UpLink Re Trans Port RF Ant UL Port TelemDone Port ObsReq Port TC : MOP : Mission Telecommand OpsPlanning CmndData Cmnd Port SC : Pt : Pointing SendCmnd Ant: Mechanical Pointing Data dl : DownLink ul : UpLink Connectivity View (Composition) Using SysML Components RF: link [KaBand] RF: link [X-band] Global structure inherited by each kind of Spacecraft … … and constrained for each kind JPL Modelling Early Adopters (MEA)

29. Execute Recv Store Transmit Cmnd Cmnd Data Data Functional View Using SysMLActivity Diagram • Showing component allocations (optional) retransReq obsComplete Finish Mission Ops Plan Prepare Accept ObsSeq ObsSeq Cmnd Data plannedObs readyCmnd Ground System Xmit Recv TT&C Network Cmnd Data retransDataReq S/C Control Spacecraft Instr Cmnd Instrument Take Obs JPL Modelling Early Adopters (MEA)

30. Informational View Using SysMLClass Diagram • Reusable, refinable information structure: <<info obj>> InstrCmndFile describes <<metadata obj>> InstrCmndMetaData <<data obj>> InstrCmndList 1 1..* <<data obj>> InstrCmnd 1..* <<metadata obj>> InstrCmndStructure <<metadata obj>> InstrCmndSemantics Global representation inherited by each kind of Information Object Derived from: SysML Partners JPL Modelling Early Adopters (MEA)

31. MOP : Mission ECU : Execution OpsPlanning Control Unit <<protocol>> TP: TransportLayer <<protocol>> TP: TransportLayer <<protocol>> IP: InternetLayer <<protocol>> IP: InternetLayer <<protocol>> LL: LinkLayer <<protocol>> LL: LinkLayer <<protocol>> PL: PhysLayer <<protocol>> PL: PhysLayer Communication View (Protocol Objects)Using SysML Component Diagram MOS : MissionOpsSystem SC : SpaceCraft CmndIn Port Cmnd Port <<controls>> SC : SendCmnd TC : TeleCmnd CmndData:RF RF: link [Xband] Derived from: SysML Partners JPL Modelling Early Adopters (MEA)

32. Communication View Using SysMLState Machine Diagram <<protocol>> TP: TransportLayer Sending evSend / transmitCount=0 Idle evDoneSend / ++transmitCount tm(Wait Time) [transmitCount<LIMIT] Waiting evACK[isValid] tm(Wait Time) Throw(“Unable to Send”) Protocol specifications inherited by each instance of Protocol Objects Derived from: SysML Partners JPL Modelling Early Adopters (MEA)

33. Developing Useful Viewpoints • Viewpoint Specification Examples • IEEE 1471 & RASDS Approach • Stakeholders, concerns, modeling language, consistency & completeness • Extensions to RASDS needed for Space System MBE • May need extended Physical (Connectivity) view • May need other views (Service) • Alignment with JPL SE Practices • Viewpoint excerpt from Rules! Doc ID 75012 JPL Modelling Early Adopters (MEA)

34. Viewpoint Elements - Functional Example • Stakeholders: system engineers, acquirers, developers, users, and maintainers • Concerns: the functions that are required for the system to meet its requirements and execute its scenarios • Modeling Language: functional objects and relationships, interfaces, behaviors, constraints • Consistency & Completeness Methods: every requirement maps to at least one function, no requirement is not mapped to a function, no function is not mapped to a requirement, and there is structural data and control flow consistency All five RASDS viewpoint elements Are documented in CCSDS 311.0-M-1 JPL Modelling Early Adopters (MEA)

35. Typical Functional Views • Functional Dataflow view – An abstract view that describes the functional elements in the system, their interactions, behavior, provided services, constraints and data flows among them. Defines which functions the system is capable of performing, regardless of how these functions are actually implemented. • Functional Control view – Describes the control flows and interactions among functional elements within the system. Includes overall system control interactions, interactions between control elements and sensor / effector elements and management interactions. JPL Modelling Early Adopters (MEA)

36. Viewpoint Elements - Connectivity Example • Stakeholders: system engineers, sub-system engineers, acquirers, developers, operators, users, and maintainers • Concerns: implemented functions, allocation to the physical structures of the system, their connections, and how they interact with the environment • Modeling Language: engineering objects (S/W or H/W), physical objects (nodes) and their connections (links), physical behavior, motion and interactions, the environment, constraints • Consistency & Completeness Methods: every functional element maps to at least one physical element, no functional element is not mapped, no physical element is not mapped to a function, and there is structural integrity and consistency JPL Modelling Early Adopters (MEA)

37. Typical Connectivity (& Physical) Views • Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the system. • Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links). • Navigation view – Describes the motion of the major elements of the system (trajectory, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids, solar pressure, gravity) Connectivity Views use different subsets of the same physical objects, but are examined from different perspectives and use different attributes. Space System MBE may require other views and object types. • Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness, attachment) • Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the thermal properties of other components (i.e. instruments as thermal sources (or sinks), antennas or solar panels as sun shade) • Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding plane) • Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other components JPL Modelling Early Adopters (MEA)

38. Connectivity(& Physical)Viewpoint - Component / Connector (Node / Link)Examples • Data System • Components (CPU, instruments, SSR) • Connectors (network, data bus, serial lines, backplane) • Telecomm • Components (transmitter, receiver, antenna) • Connectors (RF link, optical link, waveguide) • Structural • Components (S/C bus, physical link, arm, struct attrib of other components) • Connectors (joint, bolt (incl explosive), weld) • Power • Components (solar panel, battery, RTG, switches, power attrib of other components) • Connectors (power bus) • Thermal • Components (cooler, heater, thermal attrib of other components) • Connectors (heat pipe, duct, free space radiation) • Propulsion • Components (motor, wheel, thruster) • Connectors (contact patch, gravity ) JPL Modelling Early Adopters (MEA)

39. JPL SE Practices, Doc 75012 Table 3. Architectural Viewpoints • 1 Programmatic • a. Purpose, scope, and objectives • b. Organization, including the work breakdown structure ... • 2 Functional • a. Functional decomposition of the system into objects that interact at interfaces • b. Behavior of the functional elements and their functional relationships ... • 3 Physical • a. The physical decomposition of the space system into components that interact across connectors. • b. The physical aspects of the space system and the external environment within which it operates, the physical behavior (and motion) of the components relative to the environment ... • 4 Information • a. Semantics of the information and the information processing performed • b. Information managed by the space system and the structure, content, semantics, type, and relationships among the data used within the system ... • 5 Software Engineering • a. Allocation of abstract functions to selected physical components of the system. • b. Selection of approach for designing and implementing software components. • c. Design of control systems, consideration of subsystem interactions, control system elements, and elements of system under control ... • 6 Technical Infrastructure and Standards • a. Selection of technology and standards to develop the space system. • b. Standards and technologies chosen to provide the communications, processing, functionality and presentation of information in the space system ... • 7 Lifecycle Phases • a. Development • b. Integration • c. Assembly, test, and launch operations (ATLO) [verification and validation (V&V)] ... JPL Modelling Early Adopters (MEA)

40. Summary • Many different methods can be used to model space system and data system architectures • RASDS / IEEE 1471 concepts of viewpoints and related formal methods can be directly used to support space data system designs • Several projects have used RASDS successfully, ask for details • An approach for adapting SysML to add useful views has been presented • There is work being done on UML for ODP and DoDAF profiles • Even in a “document driven” process adopting an appropriate set of views is a powerful way to structure information • Word & PowerPoint • This is aligned with latest JPL SE Practices, Doc 75012 • Moreover, adoption of a formalized modeling environment based on SysML will aid description of complex system architectures • Templates or profiles supported by the tools themselves (and adaptable) • Links and relationships managed by tools • Formalized models, integrated requirements & design • Next Steps: Develop an architecture profile for use at JPL • Use SysML tool in combination with RASDS or adapted views • Document a basic practice for doing model based design in this environment • Use the approach & tool on a real project JPL Modelling Early Adopters (MEA)

41. BACKUP JPL Modelling Early Adopters (MEA)

42. Definitions of DoDAF Views JPL Modelling Early Adopters (MEA)

43. DoDAF Elements and Their Relationships(Partial and not Exact) Performs Operational Activity Operational Node Is Implemented By Owns Hosts System Function System Node Generates or Consumes Is Exchanged Between System Data Source: Takahiro Yamada, SAWG Chair JPL Modelling Early Adopters (MEA)

44. Correspondence Between RASDS and DoDAF Elements Source: Takahiro Yamada, SAWG Chair JPL Modelling Early Adopters (MEA)

45. Correspondence Between RASDS and DoDAF Views (1/2) Source: Takahiro Yamada, SAWG Chair JPL Modelling Early Adopters (MEA)

46. Correspondence Between RASDS and DoDAF Views (2/2) Source: Takahiro Yamada, SAWG Chair JPL Modelling Early Adopters (MEA)

47. Unified Object Representation Management Interfaces: How objects are configured controlled, and reported upon Object Service Interfaces: How services are requested & supplied External Interfaces: How external elements are controlled Core Functions What the object does Concerns: Issues Resources Policies JPL Modelling Early Adopters (MEA)

48. 1..n 1..n Information Object Information Object Data Object Data Object Representation Information Representation Information Semantic Information Semantic Information Structure Information Structure Information Information ObjectsRelationship to Functional View S/C Event Plans Observation Plans Directive Generation Command Execution Directive Execution Operation Plans Actual Data Objects Commands S/C Commands Realization Realization Command Schema & Structure Definition Operations Plan Schema & Structure Definition Instrument Commands Data Models Information Objects are exchanged among Functional Objects Instantiation Instantiation • Information Concerns: • Structure • Semantics • Relationships • Permanence • Rules Abstract Data Architecture Meta-models