Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Elmund Egivand]

Project Sebestačný, by Elmund Egivand

Introduction:

I am writing this blurb as an attempt to organise my work for the perusal of one Ms. Felise Selunix and to keep track of what I had done thus far. I am not proud to mention that due to my lack of an actual formal education (I was educated via an apprenticeship system, and as such the only certificate I do hold are from later periods of my formation years, namely, my graduation from the RMS and from the Eve University), I am rubbish at writing reports of any kind. Also, while I do keep notes and I do draw blueprints, I do not put down any of my overarching ideas. They are all in my head, you see.

What I, and anyone else (especially Ms. Felise Selunix), am about read is literally my mental diarrhea.

I will start with what 'Project Sebestačný' is and isn't. As the name suggests, it is about making a starship 'self-sufficient'. It is, however, also an impossible project, for a starship can't be 100% self-sufficient. She can't feed herself, clothe herself and, well, do everything at once. I do not expect to build a ship that can harvest resources, process resources into usable products and then sustain herself with said products. She will still need to dock up to resupply and she will still need technicians and engineers to repair any extensive damages she had sustained during her forays into the void. Moreover, I still need to leave the capsule and feed myself. Hydrostatic pod fluids do not contain infinite nutrients, dissolved oxygen and amino acids.

Now that I have gotten what the Project isn't out of the way, I will get to what the Project is.

It's about being able to operate under stress for long periods of time without the support of non-capsuleer crew.

I am not going to discuss my motives for trying to do such a thing.

The first step to reducing reliance on crewmates is to apply automation systems, supported by the internet of things. Cargos are tagged with RFID, cranes come with scanners, conveyor networks, loader arms and feeder systems keep weapons loaded, targeting computers work in conjunction with sensory suite to operate as fire control directors, and the shipboard AI directs all of them and etc.

However, with so much motion, the ship becomes much more vulnerable to accumulated damage.

Before I continue, I must first describe the two kinds of damage a ship will sustain throughout her voyage:

1. Micro-damage - micro-cracks, sedimentation, heat damage, wearing
2. Macro-damage - hull-breach, dislodged machinery, destroyed machinery

My first attempt at dealing with both these issues was to use repair drones. These drones were provided by one Aracturus, whom I have not heard from for quite a number of years (I'm not really good at keeping track of time). These drones also have their set of problems, especially their own wear-and-tear, their power consumption (brought upon their complexity, conjured as an attempt to fix any kind of damage a ship can sustain throughout her voyage), response time and the fact that they can't be everywhere at once. I had cracked open these drones, reverse engineered them and managed to make them smaller and less power hungry. While adept at performing field repairs and topping up coolant fluids and lubricant, they were rather slow in dealing with wear-and-tear damage and fried circuits.

Having learnt that I can't solve all my problems with drones alone, I started working on redundancies. Where possible, I always have two auxiliaries for each machine, to be kept offline until the primary machine fails, and devised means to mechanically transfer connection from primary machine to the auxiliaries. However, redundancies take up space. My Breacher, which I applied the system on, had only enough space for a fedo-sized object to crawl through. Any kind of dockside maintenance usually involved disassembling the entire ship. The issue with space is addressed by downsizing the automation system, though the solution isn't perfect. Micro- and macro-damage issues aren't addressed. It is clear that the applied solution will be of limited use on vessels larger than frigates.

Further details on how I make my Breacher crew-independent can be found in the following link:

https://forums.eveonline.com/default.aspx?g=posts&m=6164427#post6164427
https://forums.eveonline.com/default.aspx?g=posts&m=6164469#post6164469

I will describe my solutions for the issue of micro- and macro-damage next. There will be much to describe, therefore I will split them into their individual chapters.

[LifeNTimes]

This is awesome!

I don't want to interrupt, but I just wanted to add that Felise is quite grateful that you'd take the time to write up these resources to further the education her bratty little cousin.  She sends along her thanks.

[Elmund Egivand]

1. CURRENT MAINTENANCE SYSTEMS

Every machine has a lifespan which fluctuates depending on the frequency of use and the frequency and intensity of exposure to outside stress factors. This is especially true for a starship, which sees heavy use and is exposed to stress factors both inside (high-temperature emissions in propulsion, radioactive stress from reactors, heat and frictional stress all throughout the ship, material strains) and out (cosmic radiation, solar winds, ion clouds).

Shield technology has more or less rendered a starship impervious to the effects of cosmic radiation, solar winds and charged ion clouds (up to a certain extent for the latter two), however the technology to render said starship impervious to damages inflicted by the stress of day-to-day operations of internal machinery, propulsion systems, warp drives and power reactors is crude and reliant on human or drone intervention. The severity of these damages cannot be understated. Even the Myrmidon, which possesses some of the best automation technology in the cluster, will deteriorate to the point of only being able to achieve 50% operational efficiency after 3 days of continuous low-load usage as the damages inflicted by these stress factors accumulate. This is with automatic repair systems implemented.

Ordinarily, a contingent of maintenance crew members is at hand to perform maintenance on starship systems whenever these damages become apparent, in order to extend the operational lifespan of the starship. Depending on the size of the starship, the number of crew members can be as few as 1 (frigates) to as many as a 6,000 or more (Titans). To reduce the number of crewmen required to maintain the starship's ability to operate for extended periods of time, automatic repair systems are implemented.

These automatic repair systems come in two forms: repair drones and nanite spray nozzles. These systems have their downsides. Repair drones tend to be inflexible and have difficulty reaching damage sites positioned in spaces which would only be of inconvenience to a human crew member to reach. Nanite spray nozzles are indiscriminate and wasteful, as they simply spray their nanites all over the component hosting the damage site rather than the damage site itself.

As such, the human crewmen are still employed, though in lesser numbers, to make up for these deficiencies.

The key to achieving the goal of a crew-free starship is to devise a more efficient automatic repair system.

[Elmund Egivand]

2.1 NANITE DELIVERY SYSTEM

Within the cardiovascular system, blood, which carries nutrients, antibodies, red blood cells, soluble proteins, platelets and immune cells, is circulated throughout the body via a network of arteries and veins. Without fluid pressure, blood can't circulate to and fro via the artery and veins. A pump is needed to provide this fluid pressure and in the cardiovascular system, the heart is that pump.

In a starship, the nanites are like and unlike the platelets. They can seal up the damage, inflicted upon any part of the ship, just like the platelets, but unlike the platelets, the nanites can also repair the damage (in a biological system, the local cells repairs the damage via mitosis, though in some cases stem cells may be recruited to site of damage to adhere to the surrounding tissue and specialise into local cells, replacing cells lost in damage and repairing said damage). The nanite pump within the Engineering Deck is the heart. The nanite delivery pipes and their valves are the arteries and veins.

However, within the cardiovascular system, blood is constantly pumped throughout the body. In a starship, the nanite pumps are only activated when damage is detected and the nanites are directed to the site of damage via a system of valves, under the guidance of the starboard AI or a series of linked diagnostic computer AIs. To be more efficient, the nanites has to be constantly circulating the starship, just like the blood flowing through the cardiovascular system, so that they may repair microdamages as soon as they appear. However, this will require an additional draw from the power grid and from the available capacitor pool, reducing the amount of available power for use of modules installed into the ship.

To that end, I propose that instead of relying on a single nanite tank and a single pump, powered by a single power source, a network consisting of a series of nanite tanks, pumps and auxiliary power sources should be used instead.

The main nanite pump will utilise a smaller active pressure to drive the nanites through the pipes to the next tank within the next deck. At the same time, an auxiliary capacitor attached to this pump will tap into the power grid. Upon reaching a charge threshold, the microcontroller for this system or the deck computer will induce capacitor discharge, which activates the pump attached to the auxiliary tank to drive the nanites towards the next deck.

It must be noted that the cardiovascular system is a closed system. In current nanite delivery system, the nanites are sprayed onto the damaged component and thus, do not return to the delivery system. To mimic the cardiovascular system, the nanites leave the arterial pipes, travel through the starship components and plating or housing materials, and then return to the venous pipes (which will run parallel to the arterial pipes) and thus the circulatory system. The nanites in the venous pipes can be driven by passive pressure. To allow the nanites to be driven through components and materials, the materials and components themselves will need to be modified.


2.2 COMPONENT MODIFICATIONS

The artery does not deliver blood and its constituents straight to the tissue. Instead, blood is pumped from the artery and into the arterioles, which brings the blood closer to the tissue, and finally through the capillaries which snake through the tissue itself, before leaving the tissue via the capillaries, into the venule, and finally into the veins.

Arterioles and venules can be imitated using smaller diameter pipes branching from the main pipe towards the surface of the components of the ship systems. Mimicking capillaries however is a trickier preposition, as the capillary system has to be inside the components.


2.2.1 POLYMERS AND CERAMICS

Existing polymers and ceramics used as starship components are fiber-reinforced matrix composites. These fibers can be used as the capillaries for the ship's nanite circulatory system, however they will need to be hollowed out and modified to form a network connected to the artery and vein pipes. The fibers will need to be fragile, so that any microdamage occurring in the material will fracture these networks and release the nanites into the material to initiate the repair process. As such, the fibers used in the matrix composites cannot be replaced entirely, so as to preserve the material strength.


2.2.2 METALS

Instead of using honeycombed metals (which do not have interconnected hollow structures), metallic materials used will be metal foam composites. Solid outer layer will be connected to artery and vein pipes, with the middle layer being the foam structure and the inner layer being non-pipe-connected solid layer. This should allow the metal to preserve its mechanical properties without the added mass of circulating nanites. This method cannot be applied to power conduits, due to the lesser electrical conductivity of metal foams.


2.2.3 CIRCUIT BOARDS

Circuit board will be bathed in inert nanite-carrier fluid. Housing connected to the artery and vein pipes. This will allow nanites access to the circuit board. Valves and drainage system should be installed to the component pipe connections and housing to shut off the in-flow and out-flow of the carrier fluid in the event that the circuit board has to be replaced entirely.


2.3 NANITE DELIVERY THROUGH MACHINES

Every machine has at least one static component and at least one moving component. The moving component can be connected to the artery and vein pipes or the static component, depending on type and placement of machine, using polymer tubes. There are machine components where this method cannot be applied on, for example, the reactor turbines.

Using the example of the reactor turbine, the diamond-like graphite bearings, the connected stator surface and the connected rotor component, will be fabricated with micropores, which will allow for nanite carrier fluid to pass between these parts. The site featuring these micropores will be sealed, as per usual.

[Elmund Egivand]

3. MACRODAMAGE

Throughout her operational duration and despite every precaution, a starship will likely suffer from some form of macrodamage, be it in the form of battle damage or routine mechanical damage, for example, wear and tear, loosening of fixtures, creep and decay in propulsion systems or reactor machinery. Despite the methods of repairing microdamage before they develop into macrodamage, as discussed in chapter 2, some forms of routine macrodamage could occur. Regardless of cause, macrodamages need to be repaired by an external party.

As of current, drones and flesh-and-blood technicians, mechanics and engineers are employed for this purpose. Despite the advances in automation technology and robotics, drones are still of limited use in making intricate or complicated repairs, necessitating human involvement. In order to make a ship independent of non-capsuleer crew, one must look into the workings of the drones, understand how they work, determine their cause of their shortcomings and remedy them.

A distinction must be made between maintenance drones and repair drones. Both drones use similar tools and may share identical chassis. The difference lies in programming.

A maintenance drone runs on rigid routines. For example, upon reaching the scheduled time, the drone will deploy and travel to a starship component and perform its tasks as according to very rigidly programmed maintenance process chain. Under normal circumstances such rigidity is sufficient to replace crew entirely. A maintenance drone does not utilise any AI and runs entirely on its routines. Due to the simplicity of the maintenance programs, they can be programmed into repair drones without taxing their CPU resources.

A repair drone's programming is that of a more versatile weak AI. Upon deployment, a repair drone will begin its patrol route. Upon reaching a macrodamaged site and having detected macrodamages through its sensory equipment, the drone's AI will analyse the damages using the data collected from its sensor equipment and comparing the data to its in-built database via a damage analysis algorithm. Once the damage types and severity are determined, the AI then assembles a priority list. The AI will then create its task queue to match the priority list, retrieve its repair programs matched to this queue and executes them.

This simple AI programming suffices for most regular routine repairs, but is insufficient for repairs under high stress conditions e.g. a battle between warships. Before the drone can perform its repairs, it must first be able to detect the damage. These drones are typically armed with visual sensor and multispectral EM sensors (usually packaged into a singular hardware) which while sufficient for surface level macrodamage detection, can't detect more subtle macrodamages (e.g. a fried circuit board or a slightly misaligned bearing) or macrodamages hidden behind multiple layers of difficult-to-penetrate components (e.g. a single snapped power conduit under a mass of power conduits and coolant pipes under reinforced ceramic or metal plating).

Secondly, the algorithms for the assembly of priority list and queueing of repair tasks do not take into account of the usage of multiple drones, due to the drone AI being designed to be operate autonomously. As such, when one drone finishes repairs of one component and proceeds to another only to find that the other component is being repaired by another repair drone, it will stall, refresh its priority list and task queue and start over.

Finally, repair programs are coded as uninterrupted process chains, which do not lend itself to any sudden changes in the already existing macrodamage. For example, during the course of repairing a ruptured bulkhead, the bulkhead is torn right off its hinges by the shock of another volley fire. In response, the drone will refresh its task queue and retrieve another repair program, reassemble the queue and start over.

The solution to these shortcomings are as follow:


3.1 DRONE NETWORK

Each drone will be programmed with communication protocol to communicate and network with each other and the diagnostic computers, along with supporting algorithms for consensus-based priority list and task queue assembly. The benefit of this addition to programming and the supporting hardware are as follows:

1. The drone will be able to detect subtle or hidden macrodamages by analysing the data provided by diagnostic computers and be directed to the source of the anomalous readings.

2. All drones in the network will receive information of each individual networked drone's model and by extension their equipped tools. They will share all the macrodamage data they had gathered. This allows them to generate common priority and task queue, assign tasks based on the suitability of the model to perform said task.

3. Networked drones, being in constant communication with each other, are able to update each other of any changes in their environment e.g. another macrodamage having formed without having each individual drone's task interrupted. While an individual drone might be slow to adapt to any changes, being in a network allows the collective to respond efficiently, by immediately assigning any drone having completed their task to the new site of macrodamage without having each individual drone stall and reassess the situation and respond accordingly.


3.2 REPAIR PROGRAMS

Repair programs will not be written as a series of process chains. Instead, the programs for each type of macrodamage will be reduced to their individual steps, each of which will be packaged into their individual program modules. An algorithm for analysing the anatomy of the macrodamage and for assembly of each program module into a repair process chain based on the analysis will be written and programmed into the drone AI. The AI will also be equipped with general information data of every type of macrodamage to aid in analysis of macrodamage and assembly of priority list and task queue.

Upon detecting all macrodamages in its vicinity, either through its own sensors or by being informed of them by the diagnostic computers, the drone will be able to draw from the 'general information' data in its storage drive to assess all macrodamages and generate a priority list and task queue. The drone will then proceed to the site of macrodamage as according to this priority list and further analyse the anatomy of macrodamage. Upon doing this, the drone will do two things:

1. The drone determines that this particular macrodamage is similar to what its network had encountered in a previous incident. It runs its algorithm to retrieve the stored repair process chain program used in that incident and the relevant repair program modules. It then modifies the repair process chain with the repair program modules and then runs the new repair process chain program.

2. The drone determines that this particular macrodamage is novel. It runs its algorithm to retrieve relevant repair program modules and assembles a new repair process chain program. It then runs the new repair process chain program.

If the macrodamage develops or another macrodamage is detected under the existing detected macrodamage, the drone will stall its repair process chain program, runs the algorithm to modify the program, and then runs the new program. Upon completion of repairs, the new repair process chain program will be shared to all drones in the network and kept in their storage drives for future reference or use.   


3.3. DRONE CPU

The above solutions require additional CPU resource to draw from to run these algorithms and programs. Instead of relying entirely on upgrading existing drone CPU, the drones' communications protocol and algorithm will be written to allow for CPU resource sharing. This benefits in two ways:

1. The amount of unused CPU resource for each drone will be minimised.

2. Amount of CPU resource available for use scales with the number of drones connected to the same network in the vicinity. When more complicated series of repairs are required, more drones will be recruited into the problem deck. The recruited drones will join the existing drone network, contribute their CPU resource and make the collective able to modify their priority list and task queue a proportionally higher speed and efficiency.

[Elmund Egivand]

CONCLUSION/FURTHER WORK

The above highlights my plans for Project Sebestačný. However, it must be understood that these are just general ideas. Details to be worked on are as follows:

1. Ship architecture - Ship architecture must be modified or redesigned to accommodate the new nanite circulatory network and redesigned drone access network. This is to be done on a ship-by-ship basis.

2. Materials - Metallic foam, polymer and fiber materials will need to be studied and stress-tested to ensure their mechanical properties are suited for the project. Otherwise, substitutes will need to be found or fabricated. Substitute materials cannot be too expensive or exotic to ensure that tolerable material cost for mass production.

3. Nanite-fluid concentration - Concentration of nanites in their carrier fluid has to be calculated for cost/performance. Performance is determined by repair time to concentration. This is to be done to minimise waste and for cost considerations.

4. Drone population ratio - Determine the exact number of mouse/spider drones to large repair drones to be deployed for optimal performance efficiency to space occupation. Redundancy considerations will be included in this calculation.

5. Drone programs and algorithms - Actually code the programs and algorithms.

6. Drone chassis modification/fabrication - Current drone chassis will be assessed for their compatibility with the new hardware and with the project. If found unsuitable, new chassis will need to be designed to fit project goals.

7. Fabrication techniques - To be developed and refined to allow for mass production of self-healing materials and of project-derived ship. Emphasize on cost efficiency.