question

Mike Mayer avatar image
1 Like"
Mike Mayer asked Jason Lightfoot edited

Creating universal models between plants

All of our manufacturing plants are different, but they also have common functional areas. When we create FlexSim models for a particular plant, the models are typically mostly hand-build from scratch. We do borrow from previous work, but different DES analysts have different ways of doing things, which is fine, but there is no consistency and it leads to inefficiently reinventing the wheel in many cases.

We call these "snowflake" models because no two are the same, even though there are definite similarities (like being 6-sided, like all snowflakes). Still, each model is essentially handcrafted. This is probably not uncommon.

Our typical approach is to build the next model based on previous experience, and perhaps employ User Libraries as a way to copy-over 3D objects, Process Flow modules, FlexScript code, etc. from an existing similar model to the new one. Even simple Ctrl-C / Ctrl-V works for many items (like entire Planes full of objects). But none of it is formalized in any way.

We are wondering if anyone has had success creating easily portable functional areas of plants. Essentially composed of all 3D, or all Process Flow, or a combination of both, in a packaged set of "black boxes". These black boxes would have common agreed-upon inputs, common data formats, common outputs, and common configuration options (in case something is not quite exactly the same).

I guess you could call it the modular Lego approach to being able airlift common functionality into models, from a common library. Or, start each project with a master pre-fab model with everything stocked in it. The DES analyst then removes, rearranges, and tweaks things as needed to arrive at a model that works well for the next plant.

Kind of like carving an elephant out of granite - you start with a granite block and chip away everything that doesn't look like an elephant.

So we're looking for tips on overall strategy, successful attempts at standardization, best practices on modularity and maintainability, and maybe even what it might take to automate the creation of FlexSim models in some way that we've not yet thought of.

The end game being:

1) faster production of FlexSim models
2) predictable consistency between different plant models
3) easier maintainability, and
4) a shallower learning curve

I am sure this is a common theme for other enterprise DES users.

Thanks for any thoughts!

FlexSim 20.2.3
flexsim 20.2.3universal black box models
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Jason Lightfoot avatar image
1 Like"
Jason Lightfoot answered Jason Lightfoot edited

I've done something similar in the past - one of the larger challenges was maintaining a number of plant models (and some models with multple plants) with updates to the components within them (for which a bespoke version management system was created*) Creating modular equiment and plant isn't such a challenge once you decide the interfaces, and I found lists to work well in that role.

The solution centered mostly around user libraries and model libraries functionality which of course allows you to transport 3D objects and Process Flow, but also to have a set of user commands and predefined tools that will work with your components. When a newer library was loaded a change management mechanism updated the relevant behaviours, structures etc throughout the model while retaining elements that had been customised away from the library 'reference'.

The reference library was created and managed using an .ffm file that told FlexSim how to split up the user library tree when saving as .xml. You can make that .ffm file dynamic too so that you get individual xml files for each reference object, even as the library grows. The advantage of xml is in the merging of changes from multiple developers and having it split into multiple files will greatly reduce the effort involved in resolving conflict and increasing the success rate of automated merges.

I'd recommend creating container objects for your plants and making sure the components know how to reference information on the plant object in which they are contained. This can be done with a simple script that adds the pointer label 'plant' or 'factory' on every object which then make referencing its attributes simpler and faster than referencing by path or name. If you plan for having mutliple plants in your models then I find this forces you into using structures that work well instead of assuming that the root of your model is the factory.

Once you have a reference set of objects and interfaces it's also relatively simple to autobuild detailed models - something we also did regularly.


*We expect in an upcoming release some functionality to greatly assist with the management of objects. With that you should be able to do much of what I've described - in particular the idea of having the simple 'black box' in models which you later update with more detail just by updating its reference definition.



· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Mike Mayer avatar image Mike Mayer commented ·

Thank you Jason for your well-thought-out and informative reply.

You've given us some good points to consider; many of which we have not thought of (or even knew existed, like .ffm files).

I'll be bringing your ideas and suggestions to our DES team to chew on.

Also intrigued to see further (via FlexSim formal announcements) what's in store vis a vis the upcoming release you refer to.

Mike Mayer

0 Likes 0 ·
Jason Lightfoot avatar image Jason Lightfoot ♦♦ Mike Mayer commented ·

I hope it helps. I omitted further explaining the "Model Libraries" area of the tools folder which may prove invaluable. I used that to trigger some behaviours when saving and loading models, and to point to new locations for usercommands and macros. If you're planning a new way of organising all this I'd remain flexible and explore the current tools for a little while until you can see the upcoming functionality. At that point you can make a faster decision on how to use all the pieces to achieve your goals.

1 Like 1 ·