Optimizing the Smart Factory

Posted on by
Reply

In the same way that a product development involves prototyping, the production process for manufacturing that product should also be optimized for maximum efficiency and productivity.Discrete Event Simulation (DES) software approximates the manufacturing process into individual events, so can be used to model each step in manufacturing process for overall performance optimization.

The IT innovations of Industry 4.0 allow data collected from its digitalized component systems in the Smart factory to be used to simulate the whole production line using Discrete Event Simulation software.

Real time information on inventory levels, component histories, transport, logistics and much more can be fed into the model, developing different plans and schedules through simulation. In this way, alternative sources of supply or production deviations can be evaluated against each other while minimizing potential loss and disruption.

When change happens, be it a simple stock out or equipment breakdown or an unexpected natural disaster on a huge scale, Discrete Event Simulation software can produce models showing how downstream services will be affected and the impact on production. Revised courses of action can then be assessed and a solution implemented.

The benefits of using Discrete Event Simulation software to schedule and reduce risk in an Industry 4.0 environment include assuring consistent production where costs are controlled and quality is maintained under any set of circumstances.

Scheduling in the Industry 4.0

Posted on by
Reply

Today started badly.

As soon as I hopped into my car, the GPS system was flashing red to show queues of stationary traffic on my regular route to the office. Thankfully, the alternative offered allowed me to arrive on time and keep my scheduled appointments.

In the same way as a GPS combines live traffic data with an accurate map of the city, Simio Software connects real time data sources with a modeled production situation. Just like a GPS, Simio can also impose rules, make decisions, schedule and reschedule.

The major difference is in the scale.

Simio Simulation and Scheduling Software can model entire factories, holding huge quantities of detailed data about each resource, component and material. It leverages big data analysis to run thousands of permutations of scenarios, finding the optimum outcomes for specific circumstances. Lightning fast, it can detect and respond to changes with suggestions that will keep everything flowing in the best possible way.

Thank goodness for Simio, because Industry 4.0 is here.

Smart Factories employ fully integrated and connected equipment and people, each providing real time feedback about their state. Data is constantly collected on each product component, for process monitoring and control. Every aspect of the entire operation is managed through its associated specifications and status data. This large, constant stream of information coming from a known factory configuration can be received, stored, processed and reported upon by the powerful Simio software.

With Industry 4.0, nothing is left to chance. Everything is monitored and optimized, and performance is predicted, measured, improved and adapted on an ongoing basis. Management of so many interconnected components requires a scheduling system that is specifically designed to operate in this dynamic data environment. Simio Production Scheduling Software can be relied upon to provide the integrated solution for enabling technology in the Smart Factories of the future.

We are already seeing a rise in robotics and the increasing digitalization of the manufacturing industry under the effects of Industry 4.0. Soon all components of the factory model will be interconnected, just like my future driverless car that will communicate directly with my GPS to take the best route using current traffic information.

All I will have to do is sit back and enjoy the ride.

Simio Presents the 2017 User Group Meeting

Posted on by
Reply

Simio is pleased to announce the 1st Annual Simio User Group Meeting, scheduled for May 24-25, 2017, in Pittsburgh, PA. This meeting will be very interactive and informative for current or future users of Simio’s simulation and scheduling software.

The meeting will be held at the Drury Plaza Hotel Pittsburgh Downtown, which is a brand new hotel built in the historic Federal Reserve Bank building.

Who Can Attend?

Anyone currently using Simio’s simulation and scheduling software for any industry is invited to attend. Alternatively, if your company is considering using Simio software, we invite you to attend, as well, to gather more information about the product and how it can help you.

What to Expect

This meeting will be jam-packed with great presentations, advanced learning seminars and outstanding networking opportunities with Simio users and employees. With your registration, you will also receive meals, a book including all of the papers presented at the meeting for both days, and a special Pittsburgh themed gift!

There will be plenty of information to go around, so if you’ve invested in Simio, you won’t want to miss this event. You’ll be able to see real user experiences and get some great feedback on how to better utilize the software to generate even greater results.

Information for Presenters

If you currently use Simio software and would like to present a paper at the User Group Meeting, we’d love to hear from you.

All the paper needs is the following information:

  • A brief overview of your company
  • Why you chose Simio
  • The approach used in Simio
  • Results achieved by using Simio

Pricing Information

A block of rooms are reserved. However, in order to receive the discounted rate to the hotel, you must book your room on or prior to April 20, 2017. The prices for the event itself are:

  • Early Registration (before April 14, 2017) – $50 for attendees, $40 for presenters
  • Open Registration (before May 12, 2017) – $60 for attendees
  • Late Registration – $100 for attendees

Note: All presenters must be registered by April 14, 2017.

We encourage you to attend this event so you can learn more about Simio success stories. Be sure to sign up today to secure the early registration rate.

Hope to see you there!

Eric Howard

VP of Marketing

Why Daily Plans Fail

Posted on by
Reply

At 6:00 Monday morning I create a plan for my day starting at 7:00. That doesn’t seem to be such a difficult task. Why is it that by 7:30 my plan already shows signs of being hopeless?

I’ve done the obvious things. First I upgraded from a magnetic Gantt chart based on hand-written information to Advanced Planning and Scheduling (APS) software. That was much easier to use, but frankly the results didn’t dramatically improve. Feeding it with live data from my Manufacturing Execution System (MES) got me a good starting point, with a lot less effort than the paper approach, but my plan still didn’t hold up to the test of time.

I then realized that my software was based on standard lead times and it assumed infinite capacity — it was constantly overestimating my production capability. So I updated to Finite Capacity Scheduling (FCS) software. That helped a lot. But I still had a lot of problems because the FCS tool was based on a “standard” data model for my industry. I guess we do things a bit different than most people in our industry, but the schedule it generates doesn’t recognize those differences.

So I updated to a general purpose simulation product with the flexibility to model my system as it really is AND generate the Gantt charts and other reports I need for scheduling. So now I can account for that problem aisle where my lift trucks get so congested. And I can account for that machine cluster that shares access to a single crane. As a bonus I also got an animation that lets me “play out” the day and visually see what I can expect.

Now I have a much better plan that is realistic and accurate as long as everything goes well. But it is always optimistic. While I can put in preventative maintenance, there is no way to factor in that my Cobalt 120 machine is 30 years old and breaks down almost every day. Or that my supplier for Jenkins 257 material is often way behind their promised delivery. I can pad the schedule to allow extra time, but that just guarantees that I will waste valuable production time when things go well.

In my simulation tool I can run my model with all that variability accounted for (stochastic analysis) and it gives me good long-term capacity analysis. But since there is no way to predict a specific “random” problem, like an equipment failure, I can’t use that knowledge in generating my plan for today — I am limited to a deterministic schedule … or am I?

Actually there is a new technique available called Risk-based Planning and Scheduling (RPS) that first generates a deterministic plan, then applies a stochastic analysis to that plan. It actually tells me how likely it is that I will meet the plan. For example, orders that require the Cobalt 120 machine or Jenkins 257 material may show a high risk of not completing on time. Since I know this before the shift starts, I have more options on how to deal with it – like adjusting labor assignments, rerouting a process, or expediting a material. I can even evaluate the various alternatives to determine which one performs best, and then base my plan on the alternative that generates an acceptable risk at the lowest cost.

Now that’s a plan I can live with!

Happy Modeling!
Dave Sturrock, VP Operations, Simio LLC

Simulation – What a Bother!

Posted on by
Reply

I don’t know why so many people waste so much time using simulation. I just ask Joe. Joe has worked here for 38 years and he’s seen it all. Joe is always willing to take the time to tell me how that proposed system or new process will work, because he knows how well it worked or didn’t work the last time we tried something similar.

Yea, things may be different now, but the technology is about the same right? And our supply chain isn’t changing. And customer demands are the same as they were 20 years ago. And Joe’s not going anywhere … I’m sure that rumor about Joe retiring next year is just a rumor – he wouldn’t leave us hanging like that.

Well if Joe does leave I’ll just use spreadsheets. I’m pretty good at Excel. I even know how to link multiple worksheets together and get totals, averages and even charts. So I can certainly capture enough of the details to predict system performance. There isn’t that much interaction between different system components. I can figure out how to deal with seasonal variation in a spreadsheet. Our equipment, suppliers, and people are pretty reliable so there is no reason I should have to deal with things like equipment downtime, late materials, and no-shows – they probably don’t have much impact on my system.

If I need to, maybe I can figure out how to use analytical techniques like queueing theory or linear programming. After all, there is nothing complex about my system. And someone once told me that queueing theory is easy if your system is simple enough.

So I’ll let others use simulation to exactly model their complex systems and fully account for variability. Who cares about 3D animation that helps everyone understand the system and better communicate? Not me! I’m not going to bother with any of that simulation stuff.

But hey, if things go wrong and my company goes under, and you happen to see me in the unemployment line, do you think you might bother to offer me a job?

Happy Modeling!
Dave Sturrock
VP Operations, Simio LLC

Don’t Waste Your Time with a Functional Spec

Posted on by
Reply

Recently I was called in as an independent third party in a dispute between a modeler and a stakeholder. The stakeholder said “I have significant experience in both my application and modeling and I know what I want, but I am not getting it.” The modeler said “I have been modeling for 30 years and I know exactly what the stakeholder needs, but he just won’t listen to me!”

It was obvious that they weren’t communicating well, but not so obvious why two such highly experienced people were at such odds. So my first question was “What was written in the functional specification?” You might guess the answer … “What functional specification?”

My second question was “Well then, what did the contract say?” The answer again was unfortunately along the lines of “I’ll give you $x to model this” (refer to a recent blog of mine on this topic).

So in hindsight it is pretty easy to see where the misunderstanding came from. They had not agreed on model scope, approach, animation, units of measure, or even basic modeling objectives! Of course that leaves lots of room for experienced professionals to interpret the problem in totally different fashions and end up with totally different approaches to the problem.

Many people think that doing a functional specification (FS) is a waste of time. But a FS is rarely extra work. Rather it is work that must be done at some point and if it is done early it can have tremendous positive impact on project success. A FS is almost never a waste of time — even if the project is cancelled as a result of the FS, it is better to have “wasted” a few hours on the FS, rather than to have wasted significantly more time on the project before enough was learned to cancel it.

So who was right? I don’t even need to discuss the technical merits. In my perspective it comes down to two things:

1) A modeler who embarks on a journey with little clue where he is heading (an FS) is setting himself up for failure. An experienced modeler should know better.
2) While it is certainly the responsibility of the modeler to attempt to educate and persuade a client of the best approach, ultimately the customer is the one who decides if the project is successful, not the modeler. So in the end, the customer is always right.

Happy Modeling!

How Much Data Do I Need?

Posted on by
Reply

I have discussed data issues in several previous articles. People are often confused about how much data they really need. In particular, I frequently hear the refrain “Simulation requires so much data, but I don’t have enough data to feed it.” So let’s examine a situation where you have, say 40% of the data you would like to have in order to make a sound decision and let’s examine the choices.

1) You can possibly defer the decision. In many cases no decision is a decision in itself because the decision will get made by the situation or by others involved. But if you truly do have the opportunity to wait and collect more data before making the decision, then you must measure the cost of waiting against the potential better decision that you might make with better data. But either way, after waiting you still have all of the following options available.

2) Use “seat of the pants” judgment and just decide based on what you know. This approach compounds the lack of data by also ignoring problem complexity and ignoring any analytic approach. (Ironically enough this approach often ignores the data you do have.) You make a totally subjective call, often heavily biased by politics. There is no doubt that some highly experienced people can make judgment calls that are fairly good. But it is also true that many judgment calls turn out to be poor and could have benefited greatly from a more analytical and objective approach.

3) Use a spreadsheet or other analytical approach that doesn’t require so much data. On the surface this sounds like a good idea and in fact, there is a set of problems for which spreadsheets are certainly the best (or at least an appropriate) choice. But for the modeling problems we typically come across, spreadsheets have two very significant limitations: they cannot deal with system complexity and they cannot adequately deal with system variability. With this approach you are simply “wishing away” the need for the missing data. You are not only making the decision without that data, but you are pretending that the missing data is not important to your decision. An oversimplified model that doesn’t consider variability or system complexity and ignores the missing data … doesn’t sound like the makings of a good decision.

3) Simulate with the data you have. No model is ever perfect. Your intent is generally to build a model to meet your project objectives to the best of your ability given the time, resources, and data available. We can probably all agree that better and more complete data results in a more accurate, complete, and robust model. But model value is not true false (valuable or worthless) but rather it is a graduated scale of increasing value. Referencing back to that variability problem, it is much better to model with estimates of variability than to just use a constant. Likewise a model based on 40% data won’t provide near the results of one with all of the desired data, but it will still outperform the analytical techniques that are not only missing that same data, but are also missing the system complexity and variability.

And unlike the other approaches, simulation does not ignore the missing data, but can also help you identify the impact and prioritize the opportunities to collect more data. For example some products have features that will help you assess the impact of guesses on your key outputs (KPIs). They also have features that can help assess where you should put your data collection efforts to expand sample or small data sets to most improve your model accuracy. And all simulations provide what-if capability you can use to evaluate best and worst case possibilities.

Perfection is the enemy of success. You can’t stop making decisions while you wait for perfect data. But you can use tools that are resilient enough to provide value with limited data. Especially if those same tools will help you better understand the value of both the existing and the missing data.

Happy modeling!

Dave Sturrock
VP Operations – Simio LLC

General Simulation Project Approach

Posted on by
Reply

People often wonder “When is the best time to incorporate simulation into a project?” The answer, without a doubt, is at the earliest possible moment — when an idea for a significant system change or major investment is first being discussed. While it is true that at this early point in a project there are many unknowns and often very little data, simulation can still provide significant value with often a very low level of effort. While the specific issues obviously vary based on the exact systems, at these early stages you are often looking for gross measures of capacity planning and throughput analysis, impact on other facilities, and early identification of potential problem areas.

With modern tools, you can often create high-level simulation models to study such issues in not much more time than it might take to develop a comparable spreadsheet. But instead of using a spreadsheet that is limited to often misleading static analysis and fairly simple relationships, simulation can take full account of the variation and complexity present in most real systems. And as the project concepts mature, the simulation can expand and mature along with it and continually provide value at each step of the project.

For example a project might go through phases with typical questions like these:

1. Early concept validation – How will this new system work? What is the estimated capacity and throughput? What impact will this have on existing facilities? How can I communicate potential issues to stakeholders?

2. High-level system design – What components should be included? What are realistic design objectives? Evaluation of trade-offs of various investments and level of capability provided. High-level bottleneck analysis. Identify “surprises” while they are still easy to deal with.

3. Detailed system design – What specific equipment should be used (e.g., degree and type of automation)? What procedures should be implemented? What reliability can be expected and how will that impact performance and costs?

4. Implementation –Does the system perform as expected and if not, why not and how can it be “fixed”? What is the optimal staffing? When is a “change order” worthwhile?

5. Start-up – What is the impact of learning curves? What are realistic expectations during transition to full capacity? How long will that transition require? What special procedures should be put in place during that transition, what is their cost, and how soon can they be phased out?

6. Operation – How to plan and schedule the intermediate and short-term facility operation? How to effectively deal with the variability present in all systems (e.g., equipment and personnel problems, demand variation, shifting priorities, …)? How well is the system performing on the actual demand as opposed to the originally anticipated or “optimal” demand?

7. System improvement/re-design – As the system reaches stable operation, new ideas, procedures, and technologies will occur. What would be the impact of incorporating changes? Which changes have the best ROI? How do the changes relate to each other?

Until next time … Happy Modeling!

Simulationist Bill of Rights

Posted on by
Reply

In the Simulation Stakeholder Bill of Rights I proposed some reasonable expectations that a consumer of a simulation project might have. But this is not a one-way street. The modeler or simulationist should have some reasonable expectations as well.

1. Clear objectives – A simulationist can help stakeholders discover and refine their objectives, but clearly the stakeholders must agree on project objectives. The primary objectives must remain solid throughout the project.
2. Stakeholder Participation – Adequate access and cooperation must be provided by the people who know the system both in the early phases and throughout the project. Stakeholders will need to be involved periodically to assess progress and resolve outstanding issues.
3. Timely Data – The functional specification should describe what data will be required, when it will be delivered and by whom. Late, missing, or poor quality data can have a dramatic impact on a project.
4. Management Support – The simulationist’s manager should support the project as needed not only in issues like tools and training discussed below, but also in shielding the simulationist from energy sapping politics and bureaucracy.
5. Cost of Agility – If stakeholders ask for project changes, they should be flexible in other aspects such as delivery date, level of detail, scope, or project cost.
6. Timely Review/Feedback – Interim updates should be reviewed promptly and thoughtfully by the appropriate people so that meaningful feedback can be provided and any necessary course corrections can be immediately made.
7. Reasonable Expectations – Stakeholders must recognize the limitations of the technology and project constraints and not have unrealistic expectations. A project based on the assumption of long work hours is a project that has been poorly managed.
8. “Don’t shoot the messenger” – The modeler should not be criticized if the results promote an unexpected or undesirable conclusion.
9. Proper Tools – A simulationist should be provided the right hardware and software appropriate to the project. While “the best and latest” is not always required, a simulationist should not have to waste time on outdated or inappropriate software and inefficient hardware.
10. Training and Support – A simulationist should not be expected to “plunge ahead” into unfamiliar software and applications without training. Proper training and support should be provided.
11. Integrity – A simulationist should be free from coercion. If a stakeholder “knows” the right answer before the project starts, then there is no point to starting the project. If not, then the objectivity of the analysis should be respected with no coercion to change the model to produce the desired results.
12. Respect – A good simulationist may sometimes make the job look easy, but don’t take them for granted. A project often “looks” easy only because the simulationist did everything right, a feat that in itself is very difficult. And sometimes a project looks easy only because others have not seen the nights and weekends involved.

Discussing these expectations ahead of time can enhance communications and help ensure that the project is successful – a win-win situation that meets everyone’s needs.

Dave Sturrock
VP Products – Simio LLC

Simulation Stakeholder Bill of Rights

Posted on by
Reply

The people who request, pay for, consume, or are affected by a simulation project and its results are often referred to as its stakeholders. For any simulation project the stakeholders should have reasonable expectations from the people actually doing the work.

Here I propose some basic stakeholder rights that should be assured.

1. Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions.
2. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered.
3. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification.
4. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model.
5. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project.
6. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.
7. Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs.
8. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort.
9. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders.
10. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results.
11. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability.
12. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Note that every set of rights comes with responsibilities. The associated stakeholder responsibilities are discussed as part of the Simulationist Bill of Rights.

Give these expectations careful consideration to improve the effectiveness and success of your next project.

Dave Sturrock
VP Products – Simio LLC