FAQ

Frequently asked questions (FAQ) about the Facsimile project are answered within the following sections. Please review these FAQs in case your question has already been addressed, thereby saving you the time and trouble of raising a support request and waiting for a resolution.

Facsimile FAQ

This section contains frequently asked questions about the Facsimile project in general. For general questions about discrete-event simulation, refer to the Simulation FAQ; for specific technical questions about Facsimile, refer to the Technical FAQ. If you have a question that is not answered here, feel free to ask the Facsimile project by raising a support request.

F1. What are the goals of the Facsimile project?

In short, to be the best simulation/emulation tool there is.

The Facsimile project currently has the following goals:

  1. A free, open-source simulation library/framework. Free software, we believe, is better than closed, proprietary software for a wide range of reasons. For instance, commercial, closed-source simulation tools are typically expensive, restrictive and unnecessarily complex. By contrast, Facsimile is free, completely open and has a clean, extensible design. Commercial product development is typically driven by marketing departments that like adding bells & whistles rather than improving modeling capabilities, with the objective of enticing new customers to their software rather than addressing the needs of their maintenance customers. Facsimile development is driven by the needs of you, our users.
  2. High-quality, reliable software. There's nothing worse than encountering a serious bug in your simulation software when you're busy trying to meet a project deadline. We test our software throughout the development process, using a test-driven approach that highlights many bugs early on. However, no system is perfect and the occasional bug will slip through the net. When that happens, we encourage you to submit a bug report - no matter how trivial the bug - so that we can hunt it down, kill it and update our test suite to ensure that it never comes back to life. And since Facsimile is open-source, if you do find a critical bug, you can always track it down and fix it yourself (but don't forget to send us a patch for inclusion in our sources, too!).
  3. Flexible modeling paradigm. Facsimile doesn't seek to shoe-horn your modeling problems into an ill-fitting paradigm, like many other simulation tools do. For example, it does not come with pseudo-generic modeling elements such as Machines or Buffers, forcing you to decompose your problem into such constructs. Nor does it offer generic template systems for modeling Conveyors that fix the level of detail in your simulation accordingly. Instead of offering abstractions, we offer a concrete foundation upon which you can build concrete simulations.
  4. Suitable for both simulation and emulation applications. Facsimile, by adopting a non-abstract approach to modeling, allows models to be constructed from control device components such as motors, proximity switches, etc. At such a level of detail, it becomes trivial to associate such devices with one or more PLC or SCADA control systems - such that the model's operation is controlled by these control systems. This allows models to be used to debug and test control system operation prior to their commissioning. While simulations and emulations have different goals, they have a common engine. However, traditional simulation tools are generally not good at emulation and the newer emulation tools are not designed for simulation. Facsimile aims to do both.
  5. Cross-platform support. Want to run a simulation model on your Linux desktop? No problem, Facsimile plays nice with the penguin! Have a customer who uses Windows Vista (after all. no-one's perfect)? Easy! Your model will execute without modification there too! It even runs on the Apple Mac! Facsimile is not tied to any operating system or hardware, whether proprietary or otherwise.

F2. How can I get involved in the Facsimile project?

Participation in the Facsimile project is both welcomed and encouraged!

You can get involved in a number of ways, depending upon how much time you can spare and how much experience and expertise you have to offer. At its simplest, you can get involved by using Facsimile and reporting your feedback (such as filing bug reports or specifying new features). At the other end of the spectrum, you may wish to become a developer and work on the Facsimile code base, fixing those very same bugs and implementing new features. Or you could volunteer to help out with the web-site, graphic design, documentation, testing, user support - in short, whatever you may feel comfortable with.

Note that if you wish to become a developer, you will need to have accounts on both Launchpad and SourceForge, as well as on this site.

For more information, contact the development team.

Simulation FAQ

This section contains frequently asked questions about discrete-event simulation in general. For general questions about the Facsimile project, refer to the Facsimile FAQ. If you have a question that is not answered here, feel free to ask the Facsimile project by raising a support request.

S1. What is "discrete-event simulation"?

A simulation is any dynamic model that changes with time and that is used to predict the behavior of a (usually) far more complex system. The discrete-event bit is discussed in more detail below...

For example, meteorologists use simulations to forecast weather patterns and airline pilots are trained using flight simulations to prepare them for new aircraft and to cope with emergencies. In the automotive industry, simulations are used to predict how new vehicles will behave in a crash, to predict paint film thicknesses when programming painting robots and to improve throughput in assembly plants - amongst many other applications. Simulations can be used to verify extremely rapid processes (such as the execution of a new computer processor design, in which the simulation runs considerably slower than the real system) or predict how extremely slow processes evolve (such as world climate change simulations, in which the simulation runs way faster than the real system).

Simulations are useful because it's usually a lot cheaper and safer to test out scenarios on a computer than it is to do them in the real-life system. Would you rather be in a flight simulator or the cock-pit of a Boeing 747 when you want to test how well it flies on a single engine?

In some cases, it is not even feasible to observe the real-life system: watching how the weather system responds to a set of starting conditions isn't much help when you really wanted to know beforehand whether you were going to get rained on during your golf round. If you're building a new $500M production facility, would you rather just commission it and see how it performs, or would you rather simulate it first to see how well your design stands up? It's guaranteed that fixing the design on the drawing board is way cheaper than fixing your finished under-performing plant (and you will probably only annoy the plant designers, rather than your customer, project accountant and upper management).

There are two primary approaches to creating simulations. The first, termed continuous simulation, is based on solving sets of mathematical equations simultaneously. They are applicable when the state of the simulation changes continuously over time. One example of this would be a weather forecasting model in which factors such as air pressure, temperature and wind speed (amongst many others) vary according to the complex relationships between them. Such simulations tend to be deterministic; that is, they produce the same results given the same starting conditions and parameters. Examples of continuous simulation technologies include finite element analysis and computational fluid dynamics.

A discrete-event simulation is an approach based on the assumption that the state of the simulation changes at discrete-time intervals. For example, in a manufacturing environment, a single event may signal that a machine has completed a job. Discrete-event simulations are more generally applicable than continuous simulations, and can even be used to approximate the behavior of continuous simulations. Discrete-event simulations can also be stochastic (that is, they can represent random processes, such as people arriving at a bus stop or breakdowns affecting a machine) as well as deterministic. (That said, discrete-event simulations achieve their stochastic nature through a deterministic sleight-of-hand called pseudo-random number generation). Many computer simulation games use discrete-event simulation techniques.

Of course, no simulation is ever 100% accurate when predicting the behavior of its corresponding system: they are usually considerably simpler than the associated system, contain a number of assumptions (some of which may be invalid), are based upon incomplete or uncertain data (garbage in, garbage out) and may even contain bugs or logic errors. In general, the complexity of each simulation, and therefore its accuracy, is governed by its objectives. You wouldn't teach your teenage son to drive solely using Gran Turismo 5 and then realistically expect them to return your Lexus unscathed on their first trip to the store - that's not an objective of the game. However, if all you want is bragging rights over your friends, then it's an acceptable test of your relative racing skills.

Technical FAQ

This section contains frequently asked questions about specific, technical questions related to the Facsimile project. For questions concerning the Facsimile project in general, refer to the Facsimile FAQ. If you have a question that is not answered here, feel free to ask the Facsimile project by raising a support request.