AIDA "Accurate Integrated Design Architecture", both a systems engineering methodology and the associated technology, brings a new approach to understand, simplify, improve systems that have become too/very complex, which has several common ways to occur:
a_becoming complex over time, the most frequent case
Systems born simple and small (which is not the same thing), then extended over time using the same structure, appropriate at their origin but reaching its limits. It seems usually simpler to just add resources when requirements increase, not considering the architecture. System inflation inevitably reaches a breaking point, where no addition is able to satisfy more requirements.
Examples are found in any inflationist system: the amount of cars in a city, inhabitants in the planet, voted laws, sub-atomic particles, bureaucracy, ground and embarked control systems, microprocessors and software...
b_intrinsically complex from its inception on
Going straight to the simplest may given to some genius, but we usually complicate stuff at first, then hopefully simplify once the issue is better understood, in practice. Capturing the essence of a system is difficult and the fact of science, not engineering. Engineering has a set of tools and working devices and stacks them up until some behaviour is close enough to expectations. The larger a company, the easier it is to work that way, for it provides an easy consensus.
Shadow complexity is the usual state, and often encouraged as a desirable benefit when the maker also get a benefit from maintaining it, a pillar of software business.
SEA has customers who reached the limit of this model: the more "standard bricks" a wall integrates, the more cement vs brick it is made of. Interfaces become dominant and the whole system becomes heavy, slow, inefficient, expensive. It is then mandatory but very difficult to introduce a challenge: reconsidering the system from the bottom up. When this is accepted, it is surprising how simple and efficient solutions are.
c_complex because it's so strongly believed they have to be, questioning does not even arise
Working relentlessly around a problem by adding more refinements and complexity, while nobody ever sat down to reconsider the initial need. This is the Maslow say that if your only tool is a hammer this problem shall keep being a nil to you. This class of problems carries a destiny of inflation, unsatisfactoriness, extended annoyance.
...we discuss here about urban transportation as a per se unsolvable issue.
Distributed systems are known, for example the Internet, to not being strictly controlled from one central decision unit. Speaking of machines, a computer.
SEA calls "totally distributed" systems where it doesn't remain any form of central control, and the interesting part is, such systems are very special. To get there, systems are made of cells, and each one embeds:
- all the logic it needs for complete operation (no "order" is expected from elsewhere)
- all it takes to communicate with all the system, and doing so by just proximity communication
- and nothing else. A very complex cellular automaton made only of stupid cells
We talk about state-of-the-Art ones, 2016. They operate under the supervision of one computer (a centralized system) or a cluster (a federated one) equivalent to a single, big, multitasking one. This last form is generic from the complexity level of a small car on: an aircraft, a metro line, a skyscraper, a pipeline, etc. The characteristics of this approach:
- strongly heterogeneous: no single computer, no single standard network encompasses the large dynamics of performance required. Each electronics is specific to a function, each software is, numerous gateways bridge dissimilar communication methods. Everything ends up being a one-of-a-kind application specific part. Regardless, no page can be found in the huge project documentation without the word "standard" in it.
- a huge wiring harness including discrete wires and multiplexed links collects outside and internal states and forward them to the central computer(s). Synchronicity of periodically sampled data is a bit battered in the process. In discrete this downgrading is performed though noise filtering and impedance mismatches, in digital communication through medium-access protocols and over all, "communication stacks".
- in the opposite direction the harness forwards orders to the equipments, not without considerable slowdown in software, protocols, bridging, wirings since input states were measured.
- interestingly such systems are indescribable. Of course they are documented, but no one is able (luckily nobody asks) a detailed description, and certification processes typically resemble a "best effort" grant, especially where software is involved.
This approach is taken as long as it is the only one believed to exist. Limitations are perceived as just "would reach" performance levels. Engineers being good at their job, they keep digging for performance at the limit, which is exhausting a challenge, and costly.
A few decades of practice taught us that a (real-time control - ) system actually consists in few elements:
1- actuators modifying the outside world.
2- sensors to check for outside/inside conditions and check for actuators actions.
3- control laws specifying, in AIDA terms:
- expected system states = the "requirements".
- unexpected states = the safety.
- by default all other states = whatever is called a bug or failure once entered into
...and that is all. The rest is not needed by the user but by the designer. And that very "rest" is where issues, problems, costs, limitations, trouble... occur and where SEA is requested to come and cure painful details.
We can only draw the above picture because we found an alternative way through.
Curing an existing system or creating a new one comes down to the following:
a- browse the system and note where actuators/sensors are located. When some "complex" "computing" is thought as required, consider the computer as a sensor injecting some data into the system.
b- consider each physically isolated equipment, be it a turbojet or a temperature sensor, a network node and evaluate its communication needs:
1- criticality/hazard/safety level of in/out data.
2- allowed/alternative data routes
3- latency, bandwidth
4- establish the full system communication table
c- draw one minimal connex graph enabling each node to broadcast its data and propagate others'.
At this point our architecture is done.
From the graph and communication table a compiler can produce, and it is extremely important that a deterministic process can do/redo it, the implementation elements:
d- each equipment is given or already hosts a small communication & control electronics:
1- communication: an AIDA coupler performs data broadcast, collection and propagation.
Interestingly enough, the AIDA network has performance levels well beyond "standard" buses in the state-of-the-art, while in a full AIDA system, communication requirements are less than the traditional needs, due to the full distribution.
2- control: once fully distributed a System is made of many instances of a few simple equipments. A dozen types of simple controllers allow the making of any complex craft. Being local this control is vastly more powerful, efficient, detailed and safe than any traditional expense could reach.
An extremely important result is that once a pump, a cockpit display... have been implemented for say, an aircraft, they are reusable in any latter aircraft, regardless of its architecture. AIDA allows for the grail of actually reusing designs.
e- pull point-to-point serial lines between nodes. It is simpler to use a single high-bandwidth type (typ. optical or Gbps LVDS) for high bandwidth functions, and a single low-bandwidth type (100Mbps twisted wire) for low-bandwidth functions.
Note: any aircraft or car, train, ship, plant... will work fine with a cheap, standard 3.125Gbps LVDS bidir line, even if this is luxury for most equipments, and some cheapest 10Mbps twisted pair for anything usually using discrete wires and heterogeneous multiplexing. AIDA couplers easily accommodate such a large performance dynamics.
Note: in a full-AIDA system there remains no discrete wire left. A car sees a 4km to 40m harness reduction, an A380 500km+ to 5km etc. regardless of the system it is.
f- automatic generation (compiler) the messaging, taking into account nominal and alternative routes for single or multiple failures. One such compiler would require a good second to generate the complete A380 communication system.
g- automatic generation (same compiler) of routing tables that are compiled into each node coupler. This allows each node to broadcast (route out), receive (route in), propagate (route in-out) all messages.
h- power up.
1- total removal of control LRUs and their software, processors, various PCBs, power supplies, connectors, wiring harnesses, bugs, slowness, development and validation and replacement and "avionics cabinets" cost.
2- computers hosting computational algorithms only remain, at first their conservation is imposed for reason of binary code adherence (there is some). AIDA treats them as nodes who inject some input data for control purpose <=> sensors.
3- total removal of discrete wiring harnesses traditionally used for carrying signal and control. Their connectors, routes, fitting process, failures, EMI, fire, weight, cost etc. disappear too.
4- network gateways, adapters, interfaces, disappear in an homogeneous, cheap system.
5- AIDA systems are orders of magnitude cheaper to develop, build, install, own, and in safety, performance, re-usability.
The above analysis applies to systems well beyond embedded control systems, for it derives from principles in architecture, not technology.
This consideration brought SEA to concentrate our efforts since 2013 on a seemingly alien subject, but posing similar questions: urban transportation, unlike embedded control systems who are a mature discipline, is universally considered an unsolvable issue, to the point that nobody yet even tried to pose it as a problem to solve. Instead the following happens:
1- the commonly held view is that this is too complex an issue to admit but local, partial, extremely expensive (yet profitable) solutions like slicing a metro or tram line through some congested city part.
2- existing inappropriate-but-available techniques (roads, streets, automotive, bus, metro, tram, train, cable-car, etc.) keep being sold and deployed without any being envisioned as more than temporarily curing some peak congestion.
Generally, the time it takes to negotiate, buy and install such infrastructures is such that the issue to solve doubled in between, the best marker being the amount of cars around.
3- removing the most detrimental contributor to sustainable cities, the automotive (private and delivery, all that needs asphalted roads), is both universally claimed and never explicitly taken as a goal, by city planners knowing all too well this is impossible. At the most are small areas made pedestrians, which doesn't even implies delivery cars and even the dweller cars are excluded.
4- not only are cities to be freed from cars/trucks (we don't have anything against them in the countryside), but the climate catastrophe alone should already have made the topic an absolute priority. Astonishingly as of 2016 no real move is discernible.
5- too complex/expensive? Isn't it a real-time network, isn't control required? A job for AIDA.
Reasons for urban transportation to be an ideal AIDA exercise:
a- admittedly we will not come back to carrying everything and ourselves on foot, since machines allowed cities to grow immensely. Then this is definitely an engineering affair.
this means that an engineer would look for what we all do "manually" again and again and design the minimal machine to do it with an ultimate efficiency.
b- expected services are clearly known (which makes their non-satisfying even stranger), specifically moving people and goods asynchronously or isochronously on a given area with minimal latency, energy, pollutants. All is known for an expression of requirements.
let's state it: doing whatever now requires cars and delivery trucks in an urban area, ie moving people and goods from A to B isochronously (mostly periodic but with significant variations) on a given 2D area, in good engineering: minimal latency, cost, ground occupancy, pollutions (noise, GHG etc.) that is in a sustainable way.
c- let's just do the next methodological step: defining a proper architecture without putting first improper solutions because we have them. In other words being intellectually honest.
d- it comes as no surprise that we strictly applied the above exposed AIDA approach and devised, as exposed latter:
- there is a natural solution to the problem.
- it is simple and cheap and doesn't require new technologies.
- doing it the proper AIDA way is easiest/cheapest but this could also be done traditionally, and could have been since the availability of the earliest microprocessors.
- it can be done quickly, see urban-transport for more.
Contact SEA for more.