IPC Beacon Trilaterator Simulator Program intended to mix with some of the various interprocess comunication mechanisms provided by System V in Unix systems. It is composed of two basic elements. First of all, we count on a set of beacons, each one of them runs on a different process (simulating an actual device fixed on a physical location) and is a mere generator of random floating point numbers indicating the signal power. Every time a beacon generates a new signal, it adds such a value into a message queue bounded to the beacon's univoc identifier. The second component of the program is its central component, the trilaterator. It can operate in two different modes, depending on whether a eager measure or a lazy measure system is preferred. It loads the location of all the beacons available from a text file, along with their identifiers. Next, it initializes a shared memory area and starts a new thread for each one of the beacons, responsible for indefinitely capturing the input from its associated beacon (blocking itself until new data is available in its beacon's message queue, and then reading it) and storing the received value in a local fixed-length queue. Depending on the type of measure (eager or lazy) selected when the program was started, a thread will continue its operation every time it receives a new signal or will wait until it has a large enough number of values enqueued (buffering), respectively. Regardless of this, once the thread continues its operation it will pass the contents of its local queue to a filter module, which will calculate a single value resulting value by excluding values which exceed the typical deviation of the queue's population and afterwards calculating its arithmetical mean. Upon return of this value to the thread, it will write it in the position of the previously initialized shared memory area corresponding to the beacon the thread is associated to, and will signal a counter mutex semaphore. Going back to the trilaterator's main thread, after starting the subsidiary threads it will enter an infinite loop, where for every iteration it will block on the counter semaphore until every subsidiary thread has "notified" it. Once this happens, it will imply that every thread (and, consequently, each beacon) has provided a set of valid signal values, so the main thread will read every value from the shared memory area and will pass them to the trilateration/quatrilateration (depending on the number of beacons available), which will calculate a valid location inferred from the values obtained from the beacons, all of them having been processed and filtered.