�ݺ�ߣ

Editor's Notes

1. Put this in to show the format that all the slides should follow, since we will be posting this on the website…. All titles need to be this catchy orange…..
2. eVSM’s tabular Excel output transforms a VSM from a strictly graphical representation of the manufacturing of a product line to a more easily used data format which is adequate for use in simulation, depending on the data stored in the VSM.
3. I would say, you all know this…… I just put the slide in for completeness…..
4. Not sure what we are trying to say here…..
5. Completely automated build process through use of BCL scripting in addition to QUEST macro
6. Ok, that was the results from the first phase in this project. Now, let’s move on to the second phase. This step involved the work of building the Engine Line model in the second software: Enterprise Dynamics, and to also make THAT model utilize the CMSD formatted input data. 1.1. Our starting point in Enterprise Dynamics was simply nothing. Last year we had worked with a CMSD implementation in ED in a Volvo Cars Paint Shop case, but the solution we had from that was tailored for the particular simulation model being used in that case. Hence, we had to start from scratch, building a generic, reusable, and easy-to-use CMSD interface for Enterprise Dynamics. Mostly working the same way as its correspondent in Plant Simulation. [CCC] 1.2. When the interface was developed to a level good enough to use, the building of the Engine Line model started and was shortly finished. 1.3. Now having two models describing the same process and using the same input data, we have extended our solution and proven that CMSD can be used with two different simulation software. [CCC] And we will now take a look at the solution in Enterprise Dynamics, and also show how easy it is to use the CMSD interface. 2. Because of the success of our first two project phases, we now plan to extend the project to a third phase. 2.1. First of all, the translator application as it works right now, uses a lot of static data which are hardcoded in the application. Such data represents the shift schedule, name of resources etc. It can only handle data for this particular Engine Line and no other process in the Volvo Trucks factory. Besides making it more powerful, we will try to connect a third database, [CCC] maybe holding product definitions or other process related data that can be represented in CMSD and usable in the model. 2.2. The current translator analyses logged breakdown data and uses a simple distribution fitting algorithm that assumes that downtime and uptime can be described with pre-defined distribution fiunctions: The Exponential distribution and the Log-Normal distribution. Chalmers have their own distribution fitting tool under development which would be very useful if we can connect it to the Translator. A solution like that would raise the validity of the CMSD data described with distribution functions. 2.3. The current solution does not qualify to be directly implemented in the factory, but after adding what we intend to add (bullet 2.1. and 2.2.), streamline the use even more, maybe make the solution fully automatic, extend the simulation model to support experimenting that delivers usable results, we would be ready to implement it for use in the factory. 2.4. This last bullet is probably the most interesting for NIST. While working with CMSD interface development, a methodology, design and architecture has been developed that can be reusable, somewhat independent of which simulation software that you chose to build a CMSD interface for. We have developed something that we believe can be usable for building a CMSD interface for QUEST. To illustrate what how we think of this, we move to the next slide.