I would like to create a simulation of a factory floor, and I am looking for ideas on how to do this. My thoughts so far are:
• A factory is a made up of a bunch of processes, some of these processes are in series and some are in parallel. Each process would communicate with it's upstream and downstream and parallel neighbors to let them know of it’s through put
• Each process would it's own basic attributes like maximum throughput, cost of maintenance as a result of through put
Obviously I have not fully thought this out, but I was hoping somebody might be able to give me a few ideas or perhaps a link to an on line resource
update:
This project is only for my own entertainment, and perhaps learn a little bit alnong the way. I am not employed as a programmer, programming is just a hobby for me. I have decided to write it in C#.
Simulating an entire factory accurately is a big job.
Firstly you need to figure out: why are you making the simulation? Who is it for? What value will it give them? What parts of the simulation are interesting? How accurate does it need to be? What parts of the process don't need to be simulated accurately?
To figure out the answers to these questions, you will need to talk to whoever it is that wants the simulation written.
Once you have figured out what to simulate, then you need to figure out how to simulate it. You need some models and some parameters for those models. You can maybe get some actual figures from real production and try to derive models from the figures. The models could be a simple linear relationship between an input and an output, a more complex relationship, and perhaps even a stochastic (random) effect. If you don't have access to real data, then you'll have to make guesses in your model, but this will never be as good so try to get real data wherever possible.
You might also want to consider to probabilities of components breaking down, and what affect that might have. What about the workers going on strike? Unavailability of raw materials? Wear and tear on the machinery causing progressively lower output over time? Again you might not want to consider these details, it depends on what the customer wants.
If your simulation involves random events, you might want to run it many times and get an average outcome, for example using a Monte Carlo simulation.
To give a better answer, we need to know more about what you need to simulate and what you want to achieve.
Since your customer is yourself, you'll need to decide the answer to all of the questions that Mark Byers asked. However, I'll give you some suggestions and hopefully they'll give you a start.
Let's assume your factory takes a few different parts and assembles them into just one finished product. A flowchart of the assembly process might look like this:
Factory Flowchart http://img62.imageshack.us/img62/863/factoryflowchart.jpg
For the first diamond, where widgets A and B are assembled, assume it takes on average 30 seconds to complete this step. We'll assume the actual time it takes the two widgets to be assembled is distributed normally, with mean 30 s and variance 5 s. For the second diamond, assume it also takes on average 30 seconds, but most of the time it doesn't take nearly that long, and other times it takes a lot longer. This is well approximated by an exponential distribution, with 30 s as the rate parameter, often represented in equations by a lambda.
For the first process, compute the time to assemble widgets A and B as:
timeA = randn(mean, sqrt(variance)); // Assuming C# has a function for a normally
// distributed random number with mean and
// sigma as inputs
For the second process, compute the time to add widget C to the assembly as:
timeB = rand()/lambda; // Assuming C# has a function for a uniformly distributed
// random number
Now your total assembly time for each iGadget will be timeA + timeB + waitingTime. At each assembly point, store a queue of widgets waiting to be assembled. If the second assembly point is a bottleneck, it's queue will fill up. You can enforce a maximum size for its queue, and hold things further up stream when that max size is reached. If an item is in a queue, it's assembly time is increased by all of the iGadgets ahead of it in the assembly line. I'll leave it up to you to figure out how to code that up, and you can run lots of trials to see what the total assembly time will be, on average. What does the resultant distribution look like?
Ways to "spice this up":
Require 3 B widgets for every A widget. Play around with inventory. Replenish inventory at random intervals.
Add a quality assurance check (exponential distribution is good to use here), and reject some of the finished iGadgets. I suggest using a low rejection rate.
Try using different probability distributions than those I've suggested. See how they affect your simulation. Always try to figure out how the input parameters to the probability distributions would map into real world values.
You can do a lot with this simple simulation. The next step would be to generalize your code so that you can have an arbitrary number of widgets and assembly steps. This is not quite so easy. There is an entire field of applied math called operations research that is dedicated to this type of simulation and analysis.
What you're describing is a classical problem addressed by discrete event simulation. A variety of both general purpose and special purpose simulation languages have been developed to model these kinds of problems. While I wouldn't recommend programming anything from scratch for a "real" problem, it may be a good exercise to write your own code for a small queueing problem so you can understand event scheduling, random number generation, keeping track of calendars, etc. Once you've done that, a general purpose simulation language will do all that stuff for you so you can concentrate on the big picture.
A good reference is Law & Kelton. ARENA is a standard package. It is widely used and, IMHO, is very comprehensive for these kind of simulations. The ARENA book is also a decent book on simulation and it comes with the software that can be applied to small problems. To model bigger problems, you'll need to get a license. You should be able to download a trial version of ARENA here.
It maybe more then what you are looking for but visual components is a good industrial simulation tool.
To be clear I do not work for them nor does the company I work for currently use them, but we have looked at them.
Automod is the way to go.
http://www.appliedmaterials.com/products/automod_2.html
There is a lot to learn, and it won't be cheap.
ASI's Automod has been in the factory simulation business for about 30 years. It is now owned by Applied Materials. The big players who work with material handling in a warehouse use Automod because it is the proven leader.
Related
Longform Question:
When running unit tests on objects(s) whose purpose it is to track various lengths of elapsed time, is there any way to speed up the process rather than having to sit through it? In essence, if there’s a unit test that would take sixty or more seconds to complete, is there a way to simulate that test in one or two seconds. I don’t want something that will cheat the test as I still want the same comparable, accurate results, just without the minute of waiting before I get them. I guess you could say I’m asking if anyone knows how to implement a form of time warp.
Background Info:
I’m currently working with an object that can count up or down, and then does an action when the desired time has elapsed. All of my tests pass, so I’m completely fine on that front. My problem is that the tests require various lengths of time to pass for the tests to be completely thorough. This isn’t a problem for short tests, say five seconds, but if I wish to test longer lengths of time, say sixty seconds or longer, I have to wait that long before I get my result.
I’m using longer lengths of time on some tests to see how accurate the timing is, and if I’ve made sure the logic is correct so rollover isn’t an issue. I’ve essentially found that, while a short duration of time is fine for the majority of the tests, there are a few that have to be longer.
I’ve been googling and regardless of what search terms I’ve used, I can’t seem to find an answer to a question such as this. The only ones that seem to pop up are "getting up to speed with unit tests" and others of that nature. I’m currently using the MSTestv2 framework that comes with VS2017 if that helps.
Any help is greatly appreciated!
Edit:
Thanks for the responses! I appreciate the info I've been given so far and it's nice to get a fresh perspective on how I could tackle the issue. If anyone else has anything they'd like to / want to add, I'm all ears!
In 1998, John Carmack wrote:
If you don't consider time an input value, think about it until you do -- it is an important concept
The basic idea here being that your logic is going to take time as an input, and your boundary is going to have an element that can integrate with the clock.
In C#, the result is probably going to look like ports and adapters; you have a port (interface) that describes how you want to interact with the clock, and an adapter (implementation) that implements the interface and reads times off of the clock that you will use in production.
In your unit tests, you replace the production adapter with an implementation that you control.
Key idea:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies
Your adapter implementation should be so simple (by design) that you can just look at it and evaluate its correctness. No logic, no data transformations, just the simplest thing that could possibly insulate you from the boundary.
Note that this might be a significant departure from your current design. That's OK, and part of the point of test driven design; the difficulties in testing are supposed to help you recognize the separable responsibilities in your code, and create the correct boundaries around them.
Cory Benfield's talk on building protocol libraries the right way describes this approach in the context of reading data from a socket; read data from IO, and just copy the bytes as is into a state machine that performs all of the logic.
So your "clock" might actually just be a stream/sequence of timestamp events, and your unit tests then document "given this sequence of timestamps, then that is the expected behavior of the functional core".
The slower tests, that actually interact with the real clock, are moved from the unit test suite to the integration suite. They still have value, and you still want them to pass, but you don't want the delays they produce to interrupt the development/refactoring workflow.
So my issues is that, for large groups of units, attempting to pathfind for all of them in the same frame is causing a pretty noticeable slow down. When pathing for 1 or 2 units the slow down is generally not noticeable but for many more than that, depending on the complexity of the path, it can get very slow.
While my A* could probably afford a bit of a tune up, I also know that another way to speed up the pathing is to just divy up the pathfinding over multiple game frames. Whats a good method to accomplish this?
I apologize if this is an obvious or easily searched question, I couldn't really think of how to put it into a searchable string of words.
More info: This is A* on a rectilinear grid, and programmed using C# and the XNA framework. I plan on having potentially up to 50-75 units in need of pathing.
Thanks.
Scalability
There's several ways of optimizing for this situation. For one, you may not have to split up into multiple game frames. To some extent it seems scalability is the issue. 100 units is at least 100 times more expensive than 1 unit.
So, how can we make pathing more optimized for scalability? Well, that does depend on your game design. I'm going to (perhaps wrongly) assume a typical RTS scenario. Several groups of units, with each group being relatively close in proximity. The pathing solution for many units in close proximity will be rather similar. The units could request pathing from some kind of pathing solver. This pathing solver could keep a table of recent pathing requests and their solutions and avoid calculating the same output from the same input multiple times. This is called memoization.
Another addition to this could involve making a hierarchy out of your grid or graph. Solve on the simpler graph first, then switch to a more detailed graph. Multiple units could use the same low-resolution path, taking advantage of memoization, but each calculate their own high-resolution path individually if the high-resolution paths are too numerous to reasonably memoize.
Multi-Frame Calculations
As for trying to split the calculations among frames, there are a few approaches I can think of off hand.
If you want to take the multi-threaded route, you could use a worker-thread-pooling model. Each time a unit requests a path, it is queued for a solution. When a worker-thread is free, it is assigned a task to solve. When the thread solves the task, you could either have a callback to inform the unit or you could have the unit query if the task is complete in some manner, most likely queried each frame.
If there are no dynamic obstacles or they are handled separately, you can have a constant state that the path solver uses. If not, then there will be a non-negligible amount of complexity and perhaps even overheard with having these threads lock mutable game state information. Paths could be rendered invalid from one frame to the next and require re-validation each frame. Multi-threading may end up being a pointless extra-overhead where, due to locking and synchronization, threads rarely run parallel. It's just a possibility.
Alternatively, you could design your path finding algorithms to run in discrete steps. After n number of steps, check the amount of time elapsed since the start of the algorithm. If it exceeds a certain amount of time, the pathing algorithm saves its progress and returns. The calling code could then check if the algorithm completed or not. On the next frame, resume the pathing algorithm from where it was. Repeat until solved.
Even with the single-threaded, voluntary approach to solving paths, if changes in game state affect the validity of a paths from frame to frame, you're going to run into having to re-validate current solutions on a frame to frame basis.
Use Partial Solutions
With either of the above approaches, you could run into the issue of units commanded to go somewhere idling for multiple frames before having a complete pathing solution. This may be acceptable and practically undetectable under typical circumstances. If it isn't, you could attempt to use the incomplete solution as is. If each incomplete solution differs too greatly, units will behave rather indecisively however. In practice, this "indecisiveness" may also not happen often enough to cause concern.
If your units are all pathing to the same destination, this answer may be applicable, otherwise, it'll just be food for thought.
I use a breadth-first distance algorithm to path units. Start at your destination and mark the distance from it as 0. Any adjacent cells are 1, cells adjacent to those are 2, etc. Do not path through obstacles, and path the entire board. Usually O(A) time complexity where A is the boards area.
Then, whenever you want to determine which direction a unit needs to go, you simply find the square with the minimal distance to the destination. O(1) time complexity.
I'll use this pathing algorithm for tower defense games quite often because its time complexity is entirely dependent on the size of the board (usually fairly small in TD games) rather than the number of units (usually fairly large). It allows the player to define their own path (a nice feature), and I only need to run it once a round because of the nature of the game.
Currently our team of 11 people is working on a project on asp.net platform. Timeline for the project is of 8 months and we have already done 4 months. Now working on new functionalities we find that there are some flaws in the architecture of the system due to which we are facing lot of problems. Now whom to look-up for solving this ... the Team Lead or the Project Manager... Have you ever faced this scenario ? What is the best to do then..
If you've realised this and no one else has, and you want the project to succeed, then it's up to you to put a few extra hours in and figure out a plan, and then sell it to the people who are nominally responsible for the decision making.
Real projects do have "restarts". It doesn't mean that you throw away all your existing work. It means you find a new shell to fit pieces of that work into. This is a lot easier if your work-so-far consists of well-understood self-cohesive little components, loosely coupled with each other. This is why people work that way - because they know from experience that they're going to have to rearrange things. Almost all features added to programming languages over the decades are due to the fact that we know each chunk of code we write may be in for a choppy voyage - it may survive, but will probably have to cope with a lot of unfamiliar environments on the journey to release.
So you've noticed that relevant information emerges continuously, throughout a project. It doesn't conveniently all show up in a single burst right before you start typing code. Writing a specification document doesn't solve this problem at all. So you need to change the way you work so that the project draws in new information all the time - new emerging information from outside is the food that drives your project forward. Try to look forward to each new surprising revelation and greet it as a friend!
What does this mean? It means that the "architecture" parts of a project are no more stable than the "little details". You have to be able to change the architecture. You don't have enough information at the start to make a permanent decision about anything.
The underlying problem may be the fact that you have an eight month project in the first place. Real eight month projects (ones that succeed on time) are actually, if you look closely, a lot of shorter projects: 16 two week projects is ideal.
You need to put all the project's aims (so far) into a big list in priority order. Write each feature requirement from the user's perspective. "The user must be able to blah blah blah", that kind of thing. Avoid talking about the technical issues of the current design. Think about how a user would deal with having no product at all (or whatever they currently use) and talk about how their experience would be improved by a particular feature.
The important thing is the priority order. The aim is to be able to say: we only have time to ship with the first 10 items done. That's better than 9 items, which in turn is better than 8, and so on. But even with 8 items it would be better than nothing, because each item is a feature that by itself would improve the user's experience.
The list is called the backlog.
If you compare your work so far with the backlog, you'll typically find that you've been working on low priority stuff, because you imagine you'll need it later. Try not to do that from now on. The low priority stuff is... low priority. What if some new higher priority requests emerge between now and ship date? They almost certainly will! Despite what some people will claim ("It will be totally useless without feature A!"), you could probably ship with neither feature A nor feature B. But if you had to pick one, you'd go with feature A. And you may well have to ship without feature B, due to lack of time. So don't jeopardise A for the sake of being "ready" for adding B later. Only prepare in advance if it costs you next-to-nothing - leave places where you can add things, make everything extensible, but not if it slows you down right now.
Then start working on a new version of the product (cannibalising the work done so far where it makes sense) that takes care of the first few items on the list - the bare minimum. Spend no more than a week on this. A week is 6.25% of your remaining time, so it's actually pretty expensive. But at the end of this you have a picture of what you're ready to ship so far. That is the only way to measure your progress from now on.
The rest of your project consists of:
Repeatedly cranking out new working versions of the product, each time adding a few more features from the priority list. Get a small community of users to work with each version and give direct feedback to your team. Aim to do a new version every couple of weeks.
Turning the user feedback into new "stories" to go "on the backlog". This of course involves prioritising them.
You do this over and over, in short iterations, until you run out of time (you probably have time to do six to eight iterations). At the end of each iteration you have something to ship that is "better" (has more high-priority features, incorporates more feedback) than what you had at the end of the previous iteration. This is progress.
Each end-of-iteration release has two purposes: to show progress and make the user community a bit happier, of course, but also to elicit more feedback, to find out new information. Every version is both a solution and a probe. This dual nature continues after the first public release. A public release is a deep space probe that you send out into the solar system to send back pictures of strange new worlds (in the form of exception stack traces).
The whole thing is scientific and rational. You make decisions about order of work based on order of priority. You get constant feedback based on a working version of your product, instead of having to guess the feedback you'd receive from an imaginary version of your product.
People will respond to this approach by saying that it will be horribly "inefficient". Efficiency is a relative term. Projects that don't work this way always end up working this way in the end. But "in the end" is very late. Usually there's a mad panic for an extra N months after the original deadline, where the project keeps producing repeated versions of the product that are all "nearly right" or "nearly done", in a crazy self-deluded parody of iterative development.
Fortunately, you can start thinking and working this way at any time. Better to start halfway to the original deadline than shortly after it.
Just put up your issues in the team meeting that involves both the team lead and the project manager. Put forward all your views frankly and effectively. This would in turn help the future of the project and give a new insight to the PM.
Further all the 11 team members too can discuss this among themselves and share one another views.. not just about the problem... but also about the possible solution. In the end share all the valid solutions to the TL and PM. This whole process would eventually help to recover the project from this mid-development issues.
A good link for what to do is this
Raise the matter to your project manager. Present a list of options with as best an estimate as possible for time to complete each with an objective list of pros and cons.
Offer your advice as best you can, but at the end of the day it's probably not your call to make on which way it will be resolved.
For what you say it seems you have a Technical Debt.
That's a problem that every project faces, mainly because now yo have much more knowledge of the domain than 4 months before.
It's a tradeoff, if the changes are not very brutal you might pull them off. If they are radical, you might reach the deadline with some of the features and then schedule time for refactoring.
Remember, as real debt it will keep growing interests until you pay it off.
Good luck!
I'd start by getting a consensus across the team of what the issues are, and how they might be resolved. Ask yourselves: What's the overall impact? Is it a complete roadblock? Are there ways around the issues without having to make major changes? It might not be too serious, and by discussing the issues you might be able to agree an quick resolution.
I am trying to implement an exact algorithm of minimizing total tardiness for single machine. I was searching in the web to get an idea how I can implement it using dynamic programming. I read the paper of Lawler who proposed a PSEUDOPOLYNOMIAL algorithm back in 77. However, still could not able to map it in java or c# code.
Could you please help me providing some reference how to implement this exact algorithm effectively?
Edit-1: #bcat: not really. I need to implement it for our software. :( still I am not able to find any guidance how to implement it. Greedy one is easy to implement , but result of scheduling is not that impressive.
Kind Regards,
Xiaon
You could have specified the exact characteristics of your particular problem along with limits for different variables and the overall characteristics of the input.
Without this, I assume you use this definition:
You want to minimize the total tardiness in a single machine scheduling problem with n independent jobs, each having its processing time and due date.
What you want to do is to pick up a subset of the jobs so that they do not overlap (single machine available) and you can also pick the order in which you do them, keeping the due dates.
I guess the first step to do is to sort by the due dates, it seems that there is no benefit of sorting them in some different way.
Next what is left is to pick the subset. Here is where the dynamic programming comes to help. I'll try to describe the state and recursive relation.
State:
[current time][current job] = maximum number of jobs done
Relation:
You either process the current job and call
f(current time + processing_time_of[current job],current job +1)
or you skip the process and call
f(current time,current job +1)
finally you take the minimum of those 2 values returned by those calls and store it in state
[current time][current job]
And you start the recursion at time 0 and job 0.
By the way, greedy seems to be doing pretty well, check this out:
http://www.springerlink.com/content/f780526553631475/
For single machine, Longest Processing Time schedule (also known as Decreasing-Time Algorithm) is optimal if you know all jobs ahead of time and can sort them from longest to shortest (so all you need to do is sort).
As has been mentioned already, you've specified no information about your scheduling problem, so it is hard to help beyond this (as no universally optimal and efficient scheduler exists).
Maybe the Job Scheduling Section of the Stony Brook Algorithm Repository can help you.
I work for a market research company in the online space. We have been spending all of our cycles for over a year and a half building the next big thing in this space with regards to profiling our respondents (over time) to better place them in available surveys . Something that one of our researcher's has asked us for many times (rightly so) is a tool that will prove the worth of this new profiling system and predict the outcome of tweaks to it's many algorithms and rules to show which version of a rule set has a better outcome.
The goal is to be able to take a sliver of our profiling system (a static slice of Q&A data for a given time - sex:male/female, drinks:coke/pepsi/mt.dew, income:etc.) and run user agents (artificially developed software robots or agents) through our profiling system to see what the interactive results would be. As the Q&A data would be the same, the user agents abilities to choose answers would be the same, and only the algorithms and rules behind how the profiler works would change - this theoretically would allow us to pre-determine the outcome of any changes to our system. This result would then allow us to proof changes before pushing the changes to our production system. The hope would be that we could more easily catch any errors before releasing to the wild. But this would also allow us to test changes to the logic to hunt for optimizations in the profiler.
My question: For someone like me (C#/.NET mostly) who has really only worked in the web application space, where do I look to get started in building user agents that are able to interact with an outside system such as my profiling system? I specifically need to know how to spin up 1000 (one thousand) agents and have them interact with my profiling system (over a given amount of time) by being able to answer the questions that are presented to them by the profiling system based on characteristics that are dynamically defined on the user agent at the time of initialization.
An example of this is that I need some black agents, some chinese agents, some male agents, some female agents, some old agents, some new agents, some religious agents, some that drink coke, etc. and all of them mixed together to most appropriately resemble the world. We already have the demographic break down of our population so we can easily spin up 10% black males, 60% white female stay at home mothers, and all the other representations of our population.
My first thoughts for creating a system like this was to use the power of my XBOX 360, and some well thought out agents that resemble a person from an object oriented world with some added characteristics to be able to intelligently answer some questions...and guess at others.
In speaking with my colleague, it was suggested that I use some of the artificial intelligence frameworks out there and a 1000 cpu graphics card (we have one already) to get some super wicked fast performance out of loads of user agents. Where each CPU is an agent...(something like this).
Is there anyone out there with experience in this sort of thing? Proofing problems with a fictitious model of the world?
You say "interact with an outside system" - what is the interface to this system, and how does a person use it? Is it over the web? If so, you're wasting your time thinking about GPU optimisations and the like since your performance bottleneck will be the network, even over a LAN. In such circumstances you may as well just run the agents sequentially. Even if you could effectively spawn 1000 agents simultaneously (perhaps across multiple machines), chances are high that you'll just cripple the target server in an accidental denial of service attack, so it's counterproductive. However if you have the ability to change that interface to allow direct interprocess communication, you could go back to considering the massive parallelism approach. But then 1000 is not a big number in computing terms. It's likely you'd spend more time making the algorithm run in parallel than you'd save by having it that way.
As for 'artificial intelligence frameworks', I don't think there is anything quite so vague that would help you. AI and intelligent agents is a massive field - the book Artificial Intelligence: A Modern Approach which is a standard introductory text on intelligent agents is over 1000 pages long and contains maybe 20 or 30 totally independent techniques, many of which could apply to your problem, many of which won't. If you can specify more clearly what tasks the agent has to perform, and which inputs it has on which to make those decisions, picking a decent technique becomes possible. In fact, it may turn out that your problem doesn't require AI at all, if you have a clear mapping between agent demographics and decision making - you just look up the answer to use from the table you made earlier. So it's important to work out what problem you're actually trying to solve first.