Schrödinger's automotive company

Next: Secondary Effects of Self-Driving part 1

In previous post we started a segment looking at future of automative by an introduction to industry structure, how it limits innovation and where technology is going. Before going into secondary effects what self-driving cars are about to cause, a brief look at manufacturing side and what might be possible there.

Ecosystem Building

A small company can go against much bigger rivals with an ecosystem approach. This approach requires that you think and build your product with modularity in mind and allow your partners to fill in most of the modules while concentrating mostly on one key aspect that your company is good at. It also means that most of the value goes to partners from the total solution but if you are successful, you can have a formidable offer for a multitude of markets. This is the norm in software today. Open-source software allows anyone to add modules and integrations to the core to extend the reach to all possible directions.

Let’s take a hypothetical example from adjoint markets - a tractor manufacturer. Tractors have all types of attachments like excavators, tillers, drum mowers, harrows, you name it. A tractor company could build a solution by just focusing on the platform and let the partners fill in remaining.

With one caveat as for a new company to be successful, they need to prove their platform so at least for one customer segment they need to make the full solution that is better than competitors (cheaper, better total cost of ownership, better performance, more reliable, better support etc.). After that the company can let third parties add the other extensions and even replace whatever attachment was used for market entry.

If this does not work well, there is always the option of licensing the platform to bigger players who go for specific segments.

The latter part requires to create some kind of validation process so that only partners that have high enough quality standards can sell to the customer base.

As most parts will have some software in them or at least sensors, there needs to be also a software interface (API and/or wire protocol) that partners can use. And an operating system of some kind that manages this all with user interfaces, developer kits, marketing, smart phone apps so users can control the device with stuff they have and are accustomed to use.

This means that the platform company needs to build or license the operating system and hire at least a small team of developer advocates that help the partners onboard and use those APIs. Same team also takes requests for new functionalities to the software development teams. Top that with excellent documentation and various grants for new partners and bounties for faults found and good improvement ideas. These types of activities are not something most manufacturers are accustomed to do.

Ecosystem approach means also limiting own control over the product leading to safety questions. Let’s assume you build a modular car platform. When the LIDAR or some other key component used in self-driving is coming from a partner, a lot of trust rests on the perfect functioning of that component. What if their security model is weak or they introduce a software error in the future that allows adversaries to jeopardize measurement leading to hazardous results? How do we detect and mitigate that? What if customers purchase from 3^rd party markets add-ons that use our APIs and they start aggressive attacking against the rest of the car? How do we detect this and what shall we do in such a situation? Do we need to have multiple firewalls inside our product? It may be impossible to think ahead all options.

With all these caveats the ecosystem model still allows small players to appear much bigger and have a meaningful effort reaching even the biggest customers.

Sometimes the ecosystem model can be used so that even the development of the platform is omitted. A startup could pick up an open-source car platform and just focus on re-writing say just the self-driving code, making it far better than the stock one. Or take the open car platform and adjust it to a niche like for amusement parks or for beach use in some new way.

Ecosystem vs. performance

Car manufacturers today are actually following a variant of the ecosystem approach. To a great deal they are assemblers who design the car with suppliers. Most components come from a supplier, sometimes assembly is in the manufacture’s plants, sometime different partners do it.

This has the added cost of complexity as mentioned above. There are about 200 microprocessors in a modern car as of this writing. Every component like a wind shield viper is controlled by software and has its own small microcontroller. This allows partners to specialise and car brands to focus on customer experience and marketing.

Modularity brings complexity and complexity means cost. This model also prevents big changes in car design as discussed in the first post.

This creates an opportunity to greatly reduce costs and complexity by simplifying the design. Replace hundreds of smaller microcontrollers with a small number of powerful processors. This requires creating an operating system for the car where each functional part is controlled by a module (called software driver). The end result is much simpler design that reduces costs and may shorten the time for designing new generations. And many functionalities become simple software updates.

Schrödinger’s Manufacturer

Web3 ecosystem has pioneered models where incentives and control are decentralised back to the people who actually do all the heavy lifting.

In the car manufacturing model, an organisation following the web3 philosophy could work so that in the beginning the whole car company is bootstrapped by first collecting the initial capital sum for the first model design by selling governance tokens (or some other token type). The capital sum would be the seed for the Schrödinger Fund, a model we discussed in a previous post.

Buyers of the governance tokens would vote on design and manufacturing options. The designs could come from a hired design company/team or via a design competition. The final detailed car design purchased by using money from the fund. Similarly the manufacturer would be decided based on offers and voted by customers. A small project and quality team would follow the manufacturing and finally participants would get a manufactured car.

The design could be open sourced. A different approach requires design users to purchase tokens and lock them up for some defined period (stakes them in web3 parlance). The latter one would increase demand for tokens and hence raise their price.

Such a company does not necessarily have any employees. Each production batch can separately collect funds before an order is made. Sometimes to a different manufacturer. Between batches the design can be improved based on feedback from current users.

If the tokens have reasonable value, the ecosystem could be made open in a sense that anyone can join and start adding value. People helping users online to answer questions, software developers fixing errors and developing new features, people making good proposals for future or marketing successfully the concept etc. could be rewarded with tokens. Rewards could be automated for example using page-rank like mechanisms such as TechRank.

All future buyers of cars would also be given governance tokens. Then token holders could make car improvement proposals (CIPs) and vote on them. In this token model anyone interested can purchase tokens and join steering of the company.

The token sale generates income stream that is then directed back to people who have contributed to the project. Different rules can be tried. For example the original team who bootstrapped the whole thing could be given slight preference as well people who have made the best car improvement proposals (CIPs). Some small rake goes back to the fund to pay for CIP implementations and possible ongoing costs.

Using tokens it is possible to try many other models as well. A more common mechanism today is where a dedicated design team creates the first model using investor money and they reserve for themselves some set of tokens and allocate rest to participants such as customers, service technicians etc.

Case against Schrödinger car company

Increasingly the value in cars is in software. New features and improvements are software updates and the physical car is just a mandatory, dumb platform on top of which all pretty amazing new things happens. And many software features require constant feed of measurements from the cars and based on analytics, further improvements to software bits. Such features are among other things predictive care (servicing cars before faults happen) and improving self-driving. And the incoming data stream from the environment itself can be a source of income.

And to add insult to injury, reliability is a mission critical characteristics of cars. How could a free community where anyone can propose updates, guarantee this?

Perhaps cars are the most unlikely to yield themselves to the null-salaried employee model?

An argument contra this is the fact that many complex open source projects do not have permanent employees at all. And they drive industries of enormous value, some of which are mission critical. However, the contributors often have permanent position at some company that uses the software kit a lot. This could be because they sell hardware that utilises it or they sell services on top.

Same can happen in automotive as well.

Recycling as basis for new products in different verticals

Even the best of products come to an end of their life sooner or later. Wear and tear on the central expensive parts makes repair unpractical and better newer designs reduce attractiveness (safer, cheaper to use, hard to quantify customer experience is better somehow or whatever).

Material or parts can be recycled.

In today’s modular assemble-to-order car industry each car is made from a large set of modules, each of which is made to be self-standing. A car factory assembles what subcontractors ship together based on existing customer orders.

Multiple car manufacturers will use the same components even when the internal architecture of the car will have differences. A supplier cannot assume too much of the environment where the part is being plugged apart from what common industry conventions and standards say.

When a car is at the end of its lifetime, many of its modules are still quite usable. Well-functioning modules can be taken from any end-of life products, possibly refurbished (worn out parts repaired or replaced) and used for building new shiny things.

As we’ve seen in previous posts, modularity is recursive. Bigger modular units use smaller modules that in turn use even smaller components. This opens up possibilities to re-use small, modular functionalities in quite distinct domains. For example, a windscreen viper has electric motor and microcontroller that can be separately used.

A car has 200 MCUs, memory chips, Li-Ion batteries etc., many of them can be reused. A battery that no longer stores enough energy for a car, might still have years ahead in a stationary use for electric grid balancing or home energy storage, once its quality has been inspected.

Meta-manufacturer is a company that creates products without own production and without any permanent suppliers or subcontractors. Just using re-cycled parts and supplements missing bits by purchasing components from suppliers. Its existence is based on the fact that same modular building blocks are used in a multitude of industries so it has plentiful of alternative “suppliers”.

In next post we start looking at the secondary effects of autonomous cars.