Reusable Simio AssetsMichael-Anthony Tedesco & Bonnie Yue

Simio User Group MeetingMay 7, 2018

Who Are We?

2,000+ self-driving robots in over

40 countries.

Flexible and intelligent self-driving

vehicles for industrial materials

handling.

Market-leading mobile robots for

advanced research and

development.

Who Are We?

Flexible and intelligent self-driving

vehicles for industrial materials

handling.

CLEARPATH CONFIDENTIAL

OTTO Industrial Simulation Services (ISS)

ISS was formed to provide customers with insight relating to the use of OTTOs in their facility

Can I achieve my

desired

throughput?

What are potential

issues with one way

vs two way traffic

How much do I need to

spend on material

transport vehicles?

What unit load

capacity optimizes

the flow?

CLEARPATH CONFIDENTIAL

Value Simulation Brings

● Concept evaluation - Deeper insight into system workflow, early identification of risks

● Equipment sizing - Better understanding of business case

● Data driven decisions

● Concept visualization - promotes clear communication of concept, trigger concept ideas

● Marketing assets● Internal design analysis

How do design changes

impact our

competitiveness?

Do OTTOs make

business sense in this

use case?

We also use Simio for...

● Evaluation future use cases

CLEARPATH CONFIDENTIAL

Reusable Assets

Our models need to be

● quick to build

● quick to provide 1st iteration results

How can we build flexible,

scalable and reusable assets?

Why Do We Need Reusable Assets?

FASTER MODEL DEVELOPMENT

● Leverage work that has been done already

● Reduce Verification & Validation

LEARN LESSONS ONCE ONLY

● Knowledge sharing

● Quickly remember how to after long gaps

● Don’t need to sift through unrelated elements

ENABLE COLLABORATION

CONSISTENCY ACROSS PROJECTS

MANAGE CHANGES

What Are Reusable Assets?

CUSTOM LIBRARY

TEMPLATES

DOCUMENTATION

/DELIVERABLES

MINI-SIMS/SIMBITS

Where Should My Code Go?

USE CASE SPECIFIC ++ GENERIC

CO

MP

LE

XIT

Y +

MINI-SIMS

SIMBITS

CUSTOM

LIBRARY

TEMPLATE

PROJECT

MODEL

CUSTOM

STEPS (API)

CAPTURE GENERAL BEHAVIOUR

● Common across different use cases

○ e.g. Vehicle with a Battery Discharge Model

AVOID MIXING MODIFIED OBJECTS FROM CUSTOM LIBRARY WITH STANDARD LIBRARY OBJECTS

Custom Library

LIBRARY IS SPFX FILE

● Import (Load) Library file into Project file

BUILD OFF SIMIO STANDARD LIBRARY

● 2 approaches

○ Copy Base objects

○ Subclass from Base objects

● Use objects, not models

Custom Library

SIMIO BUILT ON OBJECT ORIENTED PROGRAMMING CONCEPTS

○ Subclass -> Inheritance

○ Processes -> Methods

○ Properties -> Constant/Static Fields

○ States -> Variables

CONFIGURE VS SUBCLASS

○ Configure

■ Different operation through setting different property values

■ All the process logic in 1 object class

■ Can make code more complex (lots of ifs, decides and/or exclusions)

○ Subclass

■ Different operation through separate object class definitions

■ Common behaviour through inheritance from common parent object class

Custom Library

HIERARCHY & SUBCLASSING

● Subclass all objects from Simio Standard

Library (and then don’t use Standard

Library objects)

● Most general behaviour at highest levels

Custom Library

HIERARCHY & SUBCLASSING

● Subclass all objects from Simio Standard

Library (and then don’t use Standard

Library objects)

● Most general behaviour at highest levels

● Reference objects at higher or same level

○ Reference dependency created

when casting used in process logic

○ e.g. Cart.refNextCartInTrain in

Tugger object process

Custom Library

HIERARCHY & SUBCLASSING

● Subclass all objects from Simio Standard

Library (and then don’t use Standard

Library objects)

● Most general behaviour at highest levels

● Reference objects at higher or same level

○ Reference dependency created

when casting used in process logic

○ e.g. Cart.refNextCartInTrain in

Tugger object process

● Cast most general type possible

○ Don’t use Cart.CurrentNode when

Entity.CurrentNode is available

Custom Library

HIERARCHY & SUBCLASSING

● Subclass all objects from Simio Standard

Library (and then don’t use Standard

Library objects)

● Most general behaviour at highest levels

● Reference objects at higher or same level

○ Reference dependency created

when casting used in process logic

○ e.g. Cart.refNextCartInTrain in

Tugger object process

● Cast most general type possible

○ Don’t use Cart.CurrentNode when

Entity.CurrentNode is available

Custom Library

CHECKING REFERENCE DEPENDENCIES

● Right-click object definition in Navigation window

Custom Library

HIERARCHY & SUBCLASSING (cont.)

● Beware Death Loop!

○ Parent object class references subclassed object

Mini-Sims

Simple models meant to showcase a specific functionality• Test model for component development• Base model for verification • Starting point for future model development, for efficiency & reusability• How to use components to achieve functionality, for future training purposes

Example

CPR Entity Container

Loading

Node

Unloading

Node

Template

Models that handle specific recurring use cases • Standardized mission types• Standardized parameter / tables (inputs)• Standardized experiments (outputs)

Ex. Fleet Estimation Template

Mission type

Assumptions

Metrics

Typical Development Time < half day

Model Lifecycle Management

INTERACTIONS & DEPENDENCIESMODEL LIFECYCLE A topic onto itself!

(Next year?)

Model Lifecycle Management

WHY?

● Consistency

● Traceability

○ Model History

○ Results <--Model

● Manage Dependencies

HOW?

● PDM Vault (SOLIDWORKS/DESSAULT)

○ Version Control

■ Full history with comments

■ Can roll back to previous versions

○ Manages collaboration & concurrent development

○ Only edits file properties (read-only, metadata) of Simio

■ Doesn’t corrupt SPFX files!

Best Practices

COLOUR

● Where code is executed

○ Library

■ Overwritten process

■ New process

○ Model

■ Subclassed object

■ Model Process logic

● Certain step types

○ Excluded steps

○ Temporary Steps for debugging (find and remove later)

○ Assertions (Notify Steps)

LIBRARY OBJECTS

● Provide free (not used) properties and states for common types for undefined future use

● Provide Add-on processes

○ Empower model level custom code without needing to subclass library object in model

Best Practices

ASSERTIONS

● Used to make implicit assumptions explicit

● Decide Step + Notify Step (RED)

● Steps that should never actually be reached

● Helps with model Verification

● Use Warning/Error (not Trace) in Notify Step to interrupt

execution

○ Warning will interrupt interactive run, message in

Experiment trace

○ Error will end interactive run, fail replication in

Experiment

NO MAGIC NUMBERS!!!

● Don’t hide numbers (except 1s & 0s) in step definition. Any

number should be a property, state or table value

● Properties should default to most permissive value

○ Exception: Common value that should be used

DEFINE AND DOCUMENT YOUR BEST PRACTICES

Summary

● Reusable Assets

○ reduce model development time,

○ increase consistency between models

○ facilitate collaboration and changes

● Most general behaviour in Library. Use case specific behaviour at Model level

● Recurring use-cases can be generalized into a template

● Require structure, discipline and management through the entire Model Lifecycle

● Define, document and use best-practices