Splitting insures only the failures that come alone
Assumes Splitting a sheet buys area, not certainty and A cut along the zigzag needs a tether.
Splitting a sheet buys area, not certainty set out the case for dividing a deployable. Three hundred hinges, each working 999 times in a thousand, driven as one mechanism by one actuator that works 99 times in a hundred, open completely 73 per cent of the time. Split the same hinges among ten separately driven modules and a stuck hinge strands only its own module: the share of the area expected to open rises to 96 per cent, and the chance of at least nine tenths of it to 94. A cut along the zigzag needs a tether then found the only way to divide a Miura into such modules — cut it along its zigzags and tie the strips together — and showed the gain holding at every actuator reliability.
Both essays named the assumption that makes the arithmetic clean, and both said it was the one most likely to be false. Every hinge was taken to fail on its own, with a fixed chance, whatever the others did. Correlated failures are the real ones: a stack that jams takes several hinges with it, a cold night stiffens every hinge at once, and a module whose neighbour sticks may be pulled off its path by the tether between them. The question left was whether the gain from splitting survives.
It depends on where the correlation comes from, and there are two places. A cause shared by every hinge in a deployment takes the gain back gradually, in proportion to how crowded the failures are. A tether that passes a failure on takes it back from the other end, and takes the part a mission most often needs first.
What the independent count rests on
The table above is the starting point and its arithmetic is short. A module of hinges and one actuator opens with chance . Every module is needed for the whole area, so all of it opens with chance for modules of hinges in all — 73.3 per cent at one module, 67.0 at ten, because nine more actuators are nine more ways to fail. The share expected to open is the average of the modules’ chances, which is itself: 96.1 per cent at ten modules of thirty hinges. And the chance that at least nine of the ten open is a binomial tail, 94.4 per cent.
Every one of those numbers multiplies probabilities together, and multiplying is the statement that the events are independent. The hinges’ failures are multiplied into a module’s chance; the modules’ outcomes are multiplied into the distribution of how many open. So there are two independence assumptions in the table, one inside the modules and one between them, and a correlation can break either.
Correlation between the modules alone, with each module’s chance held fixed, cannot move the expected share at all. The expected number of modules that open is the sum of each one’s chance of opening, whatever the dependence between them; that is linearity of expectation, and it holds for any joint distribution. So the first thing to settle is that a correlation which does not change any single module’s chance is irrelevant to the average and can only reshape the spread around it. Whatever takes the gain back has to work by changing what each module’s chance is — and a cause shared among hinges does exactly that.
A cause shared by every hinge
The simplest model with one number in it puts every failure in a few bad deployments. In a share of deployments the conditions are bad, and every hinge then fails with chance ; in the rest, no hinge fails at all. The average hinge still works of the time — 999 in a thousand — so a test of hinges one at a time measures the same rate at every . What changes is how the failures are distributed among deployments. At every deployment is alike and the hinges are independent, which is the table above. At the failures are packed into one deployment in a hundred, and in that deployment each hinge fails one time in ten.
Given the conditions, the hinges are independent again, so every quantity is the independent formula averaged over the two conditions. A module of hinges opens with chance , where is the failure chance the conditions set, and that average is easy to write down:
The figure follows the single mechanism and the ten modules as the failures crowd together. With every deployment alike the modules lead by 22.7 points in the share expected to open. With the failures crowded into three deployments in ten, the lead is 16.0 points; into one in ten, 6.8; into one in thirty, 1.1; into one in a hundred, nothing — the single mechanism opens 98.0 per cent of the time and the ten modules open 98.05 per cent of the area on average. Every hinge is exactly as reliable at the right of the figure as at the left, and the case for splitting has gone.
Why the whole sheet gains most
The reason is visible in the formula and it is not specific to folding. The chance that independent hinges all work, , falls fast with , and the chance under a shared cause falls slowly, because in most deployments nothing fails and in the bad ones nearly everything does. Under a shared cause, three hundred hinges behave much more like one hinge than like three hundred: they work or fail together, so the chance that all of them work is close to the chance that the conditions were good.
So the lift is largest where is largest. With the failures crowded into one deployment in a hundred, a module of three hundred hinges works 34 per cent more often than independent hinges would let it, and a module of thirty works 2.1 per cent more often. That is why the curves converge. The ten modules were already close to their ceiling, because each of their modules was small; the single mechanism was far from its ceiling, because its one module was large, and a shared cause moves exactly the thing that kept it low.
In the limit both reach the same place. When every failure is in a vanishing share of deployments, no hinge ever fails in the others, and every design opens as often as its actuators allow: 99 per cent for one mechanism, and 99 per cent of the area on average for ten modules whose actuators each work 99 times in a hundred. When hinge failures are completely shared, a deployment’s reliability is its actuators’, and splitting it into modules only multiplies the number of actuators there are to fail.
The table, read across
Read row by row, three things happen and they happen at different rates.
The one freedom climbs fastest. It goes from 73.3 per cent to 80.2, 89.6, 96.0 and 98.0 as the failures crowd into three deployments in ten, one in ten, one in thirty and one in a hundred. That is the large module’s lift, and it is worth noticing as a fact about the single mechanism on its own: a deployable whose hinges fail together is far more reliable than the hinge count suggests, and the number that the crease count is a reliability budget spent so carefully is the pessimistic end of a range.
The chance of nine tenths of the area does not move monotonically. It falls from 94.4 per cent to 91.3 at three bad deployments in ten, sits at 91.7 at one in ten, and then rises to 96.6 and 98.6. A moderate shared cause produces deployments in which several modules fail together, which a requirement of nine in ten cannot survive; an extreme one produces deployments that are almost all perfect, which it can. So a mission that wants nearly all of its area is hurt by a little correlation and helped by a lot, and the worst place to be is in between.
And the chance of all of it is exactly 0.914 times the single mechanism’s on every row. Both need every hinge to work; the modules need nine more actuators as well, and . A shared cause acting on the hinges changes what every hinge does together, so it cannot change the ratio between two designs that both need all of them. This was the cost the first essay charged to splitting, and it is the one cost no correlation of this kind relieves.
The tether as a carrier
The second source of correlation is not a cause outside the mechanism but a part of it. Modules cut from a Miura along its zigzags stand in a row, each tied to the next, and a tie that holds two strips in line when they open can also pull an open strip off its path when its neighbour sticks. A tether that carries a load also carries a failure.
The model is the plainest one with that property. Each module fails on its own with the independent chance . A module that is down — on its own account, or because it was pulled — drags each neighbour down with chance , and a module dragged down drags its own neighbours the same way, so a jam can run along the row. Each tether’s chance acts in both directions at once, so the tethers that transmit cut the row into clusters, and a cluster opens exactly when none of its modules failed on its own: to the cluster’s size. The distribution of how many modules open is then a sum over the ways the row can be cut, and it is exact rather than sampled.
The bars show what contagion does to the spread. With independent modules nearly all of the weight is on ten, nine and eight. At a contagion of 0.3, a module that sticks takes a neighbour with it three times in ten, and that neighbour takes the next three times in ten, so a single stuck hinge costs on average more than one module. The bar at nine loses most of its weight, and the bars at seven, six and below gain it. The share expected to open falls from 96.1 per cent to 93.4, and the chance of at least nine tenths from 94.4 per cent to 81.6.
The bar at ten does not move at any setting of the dial. Contagion needs a failure to start from, and the row in which nothing fails is the row in which nothing is passed on. So, as with the shared cause, the chance that everything opens is untouched: 67.0 per cent at every contagion.
Nearly all falls first
Followed across the whole range, the two measures the first essay distinguished part company. The chance of at least nine tenths falls to the single mechanism’s 73.3 per cent at a contagion of 0.57. Past that, a mission that needs nearly all of its area is better served by one mechanism than by ten tethered modules, even though the tethered modules still open more of the area on average. The expected share holds out to a contagion of 0.93, because a cascade that strands half the row in one deployment in five still leaves the average high. At a contagion of one the row is a single mechanism with ten actuators, and every quantity falls to the chance that all of it opens, 67.0 per cent — worse than one actuator, as the first essay’s arithmetic said it would be.
The ordering is the useful part. The two kinds of correlation erode the case for splitting in opposite orders. A shared cause takes the expected-share lead first and leaves the chance of nearly all roughly where it was; a tether that passes failures on takes the chance of nearly all first and leaves the expected share until the end. A solar array, which loses power in proportion to the area that does not open, is exposed to the first. An antenna or a reflector, which needs nearly all of its surface, is exposed to the second, and should be designed so that a stuck module cannot pull its neighbour — a tether that slips rather than one that holds.
How a test record tells the two apart
Neither correlation shows up in the measurement a hinge is qualified by. A hinge tested on its own, a thousand times, works 999 of them in every world drawn here; that is how the model was built. What separates the worlds is a measurement of whole deployments, and it is one that a campaign of ground tests already produces.
The count of hinges that stick in a deployment where any hinge sticks. With independent hinges, three hundred of them at one in a thousand, such a deployment has on average 1.16 stuck hinges: almost always one, occasionally two. With the same failures crowded into one deployment in a hundred, it has about thirty. Somewhere between, the number moves from near one to near thirty, and a test record that writes it down is reading directly. A record that writes down only whether the deployment worked cannot read it, because its success rate is consistent with many combinations of hinge reliability and crowding.
For contagion the reading is the same with modules in place of hinges: whether a stuck module’s neighbours fail more often than modules elsewhere in the row. Ten modules give nine pairs of neighbours a deployment, and the excess of failed neighbouring pairs over what independence predicts is the contagion, measured.
The pattern cheapest to trust priced a deployable by the number of tests needed to demonstrate it opens, and found the number growing with the hinge count. If the failures are shared, that price is too high: three hundred hinges that work or fail together behave in a test campaign much more like a few hinges than like three hundred. But nobody can claim the discount without first showing the sharing, which takes failures to show it with — and a flight article that deploys once never produces any.
The portfolio’s arithmetic
None of this is particular to paper. Dividing a deployable into independently driven modules is diversification, and the result above is the one Harry Markowitz’s 1952 analysis of portfolio selection made central to finance: diversification removes the risk that belongs to each holding separately and none of the risk the holdings share. A portfolio of ten stocks is safer than one only to the extent that they do not all fall together; in a market-wide crash they do, and the ten are one.
The folded version has one twist the financial one lacks. In a portfolio the shared risk is a nuisance that diversification fails to remove. In a deployable the shared cause also helps the undiversified design — three hundred hinges that fail together are much more reliable as a group than three hundred that fail separately — so the comparison closes from both sides at once: the single mechanism climbs while the modules stay where they were.
The same distinction runs through the account of crease error. Error is folded too found that a misplaced crease’s effect on the folded position grows with the number of creases when it is the same error every time and with the square root when it is not. That is the identical split, applied to a length rather than to a probability: what repeats adds up in full, what varies independently partly cancels, and the design question in both cases is which kind of error a process makes.
Two assumptions, named
A shared cause in two states. Every bad deployment is equally bad and every good one is perfect. Real conditions vary continuously — colder or warmer, a stowage longer or shorter — and a model with a spread of hinge failure rates would give curves between the ones drawn. The two-state model is chosen because it has one parameter and an exact answer, and because its good deployments are perfect, which makes it the sharpest form of sharing a single number can describe; nothing here shows that a smoother spread of rates lands between its curves and the independent ones, though that is what the convexity argument suggests.
Contagion along a row, the same at every tether. A real tether’s chance of passing a failure depends on how the neighbour failed, how far it got before it stuck, and how the load reaches the next module. Modules in a grid rather than a row would have four neighbours instead of two and a jam would spread faster. And both models keep the actuators independent of the hinges and of each other, which a shared power supply or a common release command would break — a correlation among actuators would cost the split sheet more than any correlation among hinges, since the split sheet has ten of them.
Whether hinges share a fate is not measured here
Whether hinge failures are shared. Nothing here measures it. The figures say what each degree of sharing would do, and the test-record section says what would have to be counted to find out where a real deployable sits; no record of that kind is cited, because the deployables this subject has produced — the solar array, the starshade studies, the tube that gets built — deploy once and publish successes.
What a module failure looks like. A module either opens or does not. A real module can stop part-way, open slowly or open and lock out of line, and a tether’s chance of passing on a failure would depend on which of those it is.
Paper. The hinges are hinges in a rigid mechanism, as in the reliability essays before this one. Nothing here depends on the creases being paper, which is the point: the reliability of a folded structure is a property of how its parts fail together, and the pattern decides only how many parts there are.
Exact averages, and a ratio held to nine places
The common-cause claims are computed exactly, as an average of the independent formulas over the two conditions, at five degrees of crowding and along a continuous curve. The figures require the split sheet’s lead in expected share to fall at every step and to be under a point at one bad deployment in a hundred, and they require the ratio of the two designs’ chances of complete success to equal to nine decimal places at every row — a ratio the model says is fixed, checked rather than assumed.
The contagion claims are exact sums over the clusters the transmitting tethers make, which gives the full distribution of how many modules open. With no contagion the expected share is required to equal a single module’s chance; the chance of nine tenths is required to fall to the single mechanism’s level at a smaller contagion than the expected share does, each found by bisection; and the chance of complete success is required to be unchanged at the contagion drawn.
The lift of a large module is required to exceed five times the lift of a small one when failures crowd into one deployment in a hundred. It is 34 per cent against 2.1.
Still open: failures that are neither shared nor passed on
Both correlations here are the simple kinds: a cause outside the mechanism that every hinge feels, and a link inside it that passes a failure along. A third kind sits between them, and it is the one a folded stack is most likely to have. Hinges that lie on top of one another in the folded state share a fate because they share a place — a stack that jams at one depth jams every hinge at that depth together — and the rows are free found exactly which panels of a folded Miura lie on which. A failure model built from the folded state’s own layers would correlate hinges by where they end up rather than by when they deploy, and it would say whether cutting along the zigzags puts the shared fates in one module or spreads them across several.
The design question that follows is concrete. If hinges that share a stack depth fail together, then a module boundary that keeps each stack inside one module protects the rest of the row from it, and a boundary that splits a stack across two modules exports the correlation into the contagion. The deciding set does not move located where an actuator decides a Miura’s folded state; where a cut should go to keep shared fates together is the same kind of question about the same sheet, asked of its failures rather than of its states.
The habit worth carrying is about independence. Before taking a benefit that comes from dividing something, ask what the parts share. Splitting buys protection against what happens to one part at a time, and nothing else; a cause that reaches every part, or a link that carries trouble from one to the next, is a reason the parts were never as separate as the arithmetic assumed — and the arithmetic that assumed it is the arithmetic that promised the gain.
What this makes readable
Essays that name this one as a prerequisite.
Named alongside this one
Essays reaching for the same objects. Nobody chose these; they are what the concept index makes visible.
- What a second deployment costs deployment · reliability · trade-off
- A gearing reflects stiffness squared actuation · degrees of freedom
- A question the record is too small to answer expected-value · independence
- A resampled maximum can only fall expected-value · independence
- Folding that gets built actuation · reliability
- Fourth of eight, and still not chosen for it degrees of freedom · trade-off
What links here
Every essay whose body links to this one.
The objects this essay names
Each one links to every other essay that touches it.
ActuationDegrees of freedomDeploymentExpected-valueHingeIndependenceReliabilityTrade-off