Basic Electromagnetic Amplitude-modulated Nexual System (BEANS): Difference between revisions

Jump to navigation Jump to search
old>Y11971alex
 
 
(One intermediate revision by one other user not shown)
Line 60: Line 60:
==Miscellaney==
==Miscellaney==
*"Beans!" became a popular phrase indicating frustration, referencing the difficulties in repairing the device when it malfunctioned, especially with insufficient lighting or under fire.
*"Beans!" became a popular phrase indicating frustration, referencing the difficulties in repairing the device when it malfunctioned, especially with insufficient lighting or under fire.
==See also==
*[[Themiclesia]]
*[[Themiclesian Army]]


[[Category:Septentrion]][[Category:Themiclesia]]
[[Category:Septentrion]][[Category:Themiclesia]]

Latest revision as of 04:37, 2 February 2020

The Basic Electromagnetic Amplitude-modulated Nexual System, or BEANS for short, was a graphics-capable communications system developed for the Themiclesian Army between 1964 and 1968. Though widely deemed unsuccessful, it has been seen by some commentators as a seminal concept for more modern digital combat-support systems. The system remained in use, in some capacity, until 1999, but in its original role it has deprecated since 1975.

System characteristics

The computer that supplied the terminals with information

Hardware

BEANS was based entirely on the System/1200 computer architecture that Themiclesian digital equipment developer and manufacturer Data Processing Systems had announced in 1965. In essence, it is a mainframe computer with its channel controllers supplemented with radio transmittors that modulated digital data over-the-air, and terminals were adapated with radio signal receivers capable of listening for these over-the-air broadcasts. Otherwise, the system functioned comparably, on a structural level, with all System/1200 mainframes at the time. The system had a basic word size of 64 bits, and another 8 bits were also present for parity check. This data was transmitted through the air in serial, not parallel. It accepted programs from punched cards, magnetic tape, and hard disk drives, and utilized magnetic core memory. The mainframe was capable of dealing with 16 simultaneous channels of data, each administered by a channel controller, which in turn communicated with several terminals sequentially.

Terminals had no independent processing power, other than basic character-generation, error-reporting, and feedback circuitry, and no user-accessible program input or storage. Terminals had a removable vector display measuring 1024 points in each dimension, with an effective viewing area of 15 inches diagonal. The transistorized terminal-side logic was stored in a sizeable box and connected to a radio transmission/reception unit, which also listened for conventional analog broadcasts at lower frequencies; for this, a headset was included. Terminals also possessed a 1kW bank of core memory as a system buffer as error checking took place. A keyboard and "control pad" were also included as standalone components; the keyboard included alphanumeric and navigation keys, standard on typewriters at the time, and the "control pad" held a bank of 25 user-definable buttons that executed specific commands. The keyboard operated electro-pneumatically.

Software

BEANS, in development c. 1966

The signalling protocol between BEANS terminal units and channel controllers is identical to that between conventional systems. Thus, the mainframe ran an operating system that supported several applications simultaneously; this was a customized version of the OS/1200 that controlled other System/1200 mainframes. The most important difference is its ability to interpret signals incoming from diverse sources, such as pictorial information from aircrafts. Computer-side, console-operators could also alter the data in the system to reflect non-digitized information. In the main, each Query Station could receive data from five applications:

  1. Map display
  2. Messenger service
  3. Announcement log
  4. Positional analysis
  5. Inventory control

An operator at a terminal could create a session in any of these programs and, using the keyboarrd, request information from the mainframe. The Map Display application displays a static map around the operator's location; the terminal could zoom and show specific features, such as topogaphy or waterways, according to user preferences. The Messenger Service established a two-way textual communication between a terminal and a console, and this was used usually to communicate directly with a superior officer or read summaries of intelligence reports. Announcement Log retains the records of all announcements issued within the previous 30 days. Positional Analysis displays a real-time map of the operator's position and enemy positions as reported by reconnaisance units. This is separate from the Map Display function as it demanded much faster reaction time, and operator were discourged from making a session on Positional Analysis longer than necessary. Inventory control allowed the operator to update his home base on the current supply situation in the field.

Challenges

BEANS by itself did not entail the creation of much new technology, but was conceived in the mid-60s as an configuration of devices that would greatly improve communication at long distances by enabling the digital delivery of both text and graphics from a source to a number of terminals (called "Query Stations" in BEANS-speak) through the super high frequency band (thus wirelessly). Theoretically, all relevant technologies to be implemented into the system already existed in 1964, but development was plagued by unsatisfactory testing results and unstable signals.

The primary catch was the strength of the broadcasting signal—too low, the terminal would not receive data coherently, and too high, it created a potential health hazard for nearby personnel. Eventually, it was decided to err on the side of caution and underpower the broadcasting signal. The clarity issue was mitigated by transmitting four simultaneous, identical signals at different frequencies, all of which the terminal listened for and which were checked for consistency. Each data stream was 64 characters long, and the source waited for the terminal to ascertain the integrity of the received signal; if the signal was negative, the stream was repeated, until the terminal responded positively. A fifth stream was later added as a parity check stream, further improving data accuracy.

Operation

The Army began preparing BEANS for field use in late 1967, consigning each brigade a complete BEANS system with a computer and 80 terminals. Each terminal was intended to be held at the platoon level, though it soon became obvious that BEANS was not as portable as it was described, and platoons moved around too much to make use of BEANS, in view of the time required to assemble all componentry. Yet because the Army was not involved in any combat during the entire lifetime of BEANS, some argue the system was never given an opportunity to demonstrate its abilities.

Specialist training

As BEANS was a novel system, the Army leadership devised a training regimen that qualified soldiers to operate BEANS alone or in pairs. If alone, the soldier must operate and maintain the machine by himself. If in a pair, then one operated the terminal, while the other was responsible for its upkeep. Both tasks were intellectually demanding, as most recruits had no personal experience with operating or maintaining a computer-related device. In the end, qualifiers were placed in the new branch of "Digital Signals Corps".

Mobility

Whenever possible, BEANS was carried on a vehicle with specialized interior to support its operation. Otherwise, it could be separated into several boxes that were carried by its operators. A BEANS terminal weighed upwards of 50 kg with everything accounted for; if the operator was alone, the other pieces were drawn with a wheeled platform, pulled by an NCO. Later, in view of the system's tremendous weight, the Army supplied specialized vehicles for all BEANS units, though for some types of maintenance and operation still need to be dismounted from the vehicle.

Data transmission

For the most part, BEANS stored and delivered the information it was designed to with good accuracy, especially computer-side. Though inefficient, data transmission was predominantly accurate, and in rare cases where errors did surface, it was easily identified as an anomaly. The system's software was stable and was available 24/7, since only parts of the computer would be under maintenanct at any one time.

Reception

Reliability issues

Throughout its service lifetime, BEANS acquired a negative reputation for being "heavy, fragile, confusing, and expensive". BEANS, though ruggedized, was still quite sensitive to impact and required calibrations, particularly to its core memory matrix, when it suffered abuse. Oftentimes, a hard smack or dropped article was sufficient to trigger the failsafe, arresting its operation and dumping memory content. The display was also susceptible to bumps and magnetic interference, easily losing its screen contents when a strong magnet neared it, and ground vibrations could generate random signals on screen or corrupt incoming images. Due to its sheer complexity, BEANS was virtually useless without its staff operating it.

On the other hand, DPS engineered BEANS to be maximally serviceable, and virtually everything in BEANS could be replaced, from transistor circuit boards to vacuum tube signal modulators. There is evidence to suggest that DPS thoroughly experimented with many possible designs and settled on the most stable they could find, and indeed BEANS functioned well under proper operating circumstances, which BEANS sought to maintain as an internal mechanism. For example, to ensure consistent data retention in the core memory module, BEANS included a heater and fan that maintained a constant 42°C in that chamber. To minimize shock to the solid-state components, the internal assembly was caged in an insulator, and the cage itself was suspended with advanced dampening systems within the outer metal shroud. However, these measures were not sufficient to prevent malfunctions when BEANS was carelessly moved, which often happened in field use or even when their staff was away.

Cost

On the surface, each complete BEANS costed $20,864,000, and four complete systems were manufactured between 1967 and 1970, totalling $83 million. Additionally, the BEANS service contract also cost $1.2 million per annum per system. The personnel training costs and operational costs were never fully tallied, but some estimates value them at over $53 million over the course of the program's lifetime.

Usefulness

Like many combat-information systems of its day, the capability of BEANS was never tested on the battlefield, as Themiclesia did not fight a single war between 1964 and 1975. When questioned, the Defence Secretary famously said, "We will use a weapon to fight a war, but we will not fight a war to use a weapon."

Seminal value

A concept pilot promoted by the OS Air Force, holding an information system purportedly inspired by BEANS

A considerable number of experts contend that BEANS was the "first of its kind" in providing an integrated information-sharing system that was implemented electronically and updated across-the-board in real time, as well as using computer technology to expedite the query process and to display graphics that assisted any commander in visualizing opponents' manoeuvres and his relative positions. A. R. Michaels of the Organized States considers this "a remarkable piece of technology that was leaps and bounds ahead of the world" and "a truly innovative application of digital logic to solve age-old battlefield problems". C. P. Crammer of New Tyran concurs with Michaels, saying that "BEANS would have ushered warfare into the information age had it been fielded in an actual war during its time".

M. L. Barter cautions against unqualified laudatory assessments. He states that the team behind BEANS was clearly quite detached from reality, especially that of a chaotic battlefield. Even in the absence of enemies, BEANS was far from a very reliable and resilient system, and under real fire, its value "is subject to very serious and very reasonable doubt". He goes on to say that the system's incredible dimensions and mass, and sensitivity to slight perturbations constituted a great challenge to its utility. A. R. Michaels rejects these stipulations as "myopic". He, instead, has stated that Barter's concerns were legitimate, but the advancements and novelty first demonstrated in BEANS would go on to revolutionize warfare and many other fields, and these shortcomings were artifacts of the technological limits of the age and should not hamper conceptual assessment 50 years after its introduction.

Future development

During the lifetime of BEANS, several other states showed intense interest in adapting the concept for their own use (military or civilian). The GA was lukewarm in its reception of BEANS; some states openly criticized the concept itself as unmanly, since BEANS gave an informational advantage over the enemy, that is, "winning a battle in a mind"; others disagreed with these value judgments and instead provided that BEANS was not supported with mature technology, and enemy tactics may not be complex or co-ordinated enough to warrant its use. Kerenevoi, however, showed persistent interest in BEANS; when BEANS was replaced with a more modest system (which was only the size of a boombox and did away with the display) in 1975, Kerenevoi, Dayashina, and the OS all showed interest in purchasing rights or a manufacturing license for BEANS. DPS, seeing comparatively little potential in the project, and to the end of disassociating itself with BEANS (which became a public fiasco by then), licensed the plans for BEANS and its manufacture to all three states. Some authorities consider these modern PDA-sized a direct continuation of the BEANS concept as first implemented in Themiclesia in 1968.

Miscellaney

  • "Beans!" became a popular phrase indicating frustration, referencing the difficulties in repairing the device when it malfunctioned, especially with insufficient lighting or under fire.

See also