Today, Monday, 2018-08-13, the real-life Ethan is 16 years old. Happy Birthday Ethan! This date also marks the day when I have spent precisely half my life as a father.
Ethan & Ethel are wanting to improve their woodworking workshop by buying a stationary machine. They estimate that using this type of machine can increase their production capacity. Because these machines are expensive, they will have to plan which one to buy first. They are thinking that if they make the right investments, they will be able to build things that others want, and make some money. For example, they have an aunt who wants a garden shed, other relatives who need new kitchen cabinets; and family friends who want hardwood furniture. However, they can’t build all these things at once, and decide to concentrate on building garden sheds.
There are many designs for garden sheds. Usually they are small uninsulated buildings. Ethel & Ethan are thinking of using softwood lumber for framing, then covering it with OSB. When they made up a cut list, they realized that they should build it using full sheets of OSB. That means dimensions of 1 200 mm, 2 400 mm or 3 600 mm. Beyond that, and the buildings would be far too big with their limited skill sets. They decided that their first building should be 2 400 mm long by 2 400 mm wide by 2400 mm high at the eaves. At the ridge, it would be 600 mm higher, or 3 000 mm. It is a small shed, but there is less that can go wrong, and less time and equipment is needed to make it.
They started thinking about pre-cutting the pieces for one shed to save time in the short building season. Then they thought that if they could pre-cut one, they could precut more. Then they contacted other people in their network to see if they could find buyers. After these conversations, they estimated that they could build and sell five of these small sheds in the summer.
They want to buy a chop saw, and know the maximum dimensions of the material they will be working with on the sheds will be about 50 mm by 100 mm. What they really want is a flipover saw, such as a DeWalt DW743. One challenge with this model is its inability to cut joists, if they work on bigger projects. The saw was originally made by the German power tool company, ELU, that was bought by DeWalt in 1994.
At the Unit One workshop, a Ryobi compound sliding mitre saw is used. It was selected because of price, and the fact that the sliding mechanism is in front of the saw. This prevents it from being used with materials thicker than about 100 mm. Most sliding saws go back towards the wall, which means that the saw has to be set further forward, increasing the amount of space used. Perhaps the best mitre saw is a Bosch axial-glide saw. Its main disadvantage is price, costing almost four times that of a Ryobi.
Lumber dimensions: A 2 × 4 when dressed is 1-1/2″ × 3-1/2″ or 38 mm × 89 mm. In Europe it is 48 mm x 98 mm.
A sliding compound mitre saw and a plunge saw make a versatile pair. Table saws are more dangerous than either of these saws, because the operator holds the material being cut, instead of the saw, making it easier to accidentally move hands into the spinning blade.
In the last post, Ethan & Ethel had to do a lot of work, to keep track of their heating costs.
Time used = Time turned off – Time turned on. Example: 17h05m – 15h31m = 94m
They wrote down the time they turned on their heater, and then the time when they turned it off. They then subtract the “on” time from the “off” time to find the number of minutes the heater was on. This had to be repeated for every visit to the workshop with heat on. At the end of the month, they had to add all of these minutes together to find their monthly usage. What a boring job, and so unnecessary when a computer can do it, automatically! All that is needed is a few lines of code. Code that has already been written, and is waiting to be reused.
Workshop computer control means that computing equipment is running hardware and software that senses and activates workshop activities.
Stop the Press!
This post was originally written 2018-03-02. It is now 2018-08-11, more than five months later. Reviewing it at the time I was dissatisfied with the previous paragraph, that continued with, “a Raspberry Pi single-board computer will be used to run Home-Assistant software. The raspberry pi will be connected to two different Arduino micro-controllers using USB cables.”
The problem, both then and now, is that while the above solution would work, it is not optimal. Why should one use three components, when one should do? Ideally, a single microprocessor should be able to run 1) home automation software, in this case Home-Assistant; 2) connect to analogue sensors and have analogue input data converted to digital data; 3) connect digitally to relays to trigger activators; 4) communicate with other components on the local area network using wires (Ethernet); 5) receive electrical power over those same wires.
The best way forward to gain an understanding of workshop problems is to pretend that the ideal solution exists, a fantasy Unicorn IoT (Internet of Things) microcontroller.
If Ethan and/or Ethel are to work in a computer controlled workshop, one of the first things they need to control is the workshop computer. It should be designed in such a way that it can respond to their needs turning on and off lights, heat, tools, etc.
While a Raspberry Pi (and its clones and near relatives) is capable of running this software, an Arduino microcontroller is not.
In a workshop there can be a large number of different sensors measuring all sorts of things. There can also be a large number of actuators using the same data. For example, both a heater and a vent may use data from a room temperature sensor, but in different ways. The heater may be activated if the work space is too cold. Once it gets hot enough it will shut off. If the temperature continues to rise, then a different actuator, the vent will be activated, but only if the outside temperature is lower than the inside temperature. To determine that, there needs to be a second temperature sensor, this one measuring the outside air.
A sensor is any device that measures a physical quantity. Temperature sensors can be found not only in the workshop space, but also inside machines. This Wikipedia article lists sensors by sensor type: https://en.wikipedia.org/wiki/List_of_sensors
Some of the other sensors in a workshop include: humidity, measuring water vapour in the air; infra red, detecting body heat; light, measuring light levels; smoke, detecting fires. Those are sensors that can be used anywhere in a house. There can be some sensors that are specific to a workshop: wood moisture content and dust particles in air.
Having so many sensors can be a major distraction, so from now on the focus will be on just one, a LM35 temperature sensor.
LM35 Temperature sensor
Several companies make temperature sensors, but Texas Instruments makes one that is world famous, the LM35. It costs about $1.50.
While information about the LM35 is available in a data sheet that contains more than enough information about every aspect of the sensor, most people don’t need to read it. Why? Because all of the engineering work has been done before. Since Ethan and Ethel will be using an Arduino, they just need to know how to connect a LM35 with an Arduino. Then they have to find a (free) program that uses the LM35, and upload it onto the Arduino. With a little practice, anyone can get a sensor working on an Arduino in about five minutes.
The LM35 is cool. The main reason is shown in this graph. Most sensors express themselves as a voltage that varies smoothly with the quantity being measured. On a graph this makes a straight line. The LM35 is exceptional, because at 0°C output voltage is 0V. Every 1°C up or down adds (with positive temperatures) or subtracts (with negative temperatures) precisely 10 mV. At 100°C, the output voltage is exactly 1V. The LM35 is also very flexible regarding input voltage. It can use anything from 4V to 20V.
Computers use digital data, and can’t normally read voltages directly. On micro-controllers there are Analog to Digital Converters (ADC) that automatically change an input voltage into a digital value. On the Arduino Uno, there are six analog pins that can read voltages from 0 V to 5 V (or 0 mV to 5 000 mV). This means that up to six different sensors can be connected to an Arduino board. There are ways to add more, if needed. Each sensor then has its voltage converted into a digital values between 0 and 1023. These analog pins have a sensitivity of 4.9 mV. So a voltage from 0 to 4.8 mV will be given a value of 0. From 4.9 mV to 9.8 mV they will be a value of 1. This will continue right up to 4 995.1 mV to 5.0 mV, where they will be given a value of 1023.
It takes about 100 µs (100 microseconds or 0.0001 s) to read an analog input. The maximum reading rate is 10 000 times a second. Usually, reading a temperature once a second is good enough. In fact, in some circumstances reading it every five minutes or every hour would make better sense, especially if all this data has to be stored.
Arduinos have ADC units, Raspberry Pis do not.
Microcontrollers do not respond well to large currents, and will be permanently damaged if connected to too many volts, amps or watts. If one wants to turn on an electric heater to warm up a space, this is typically done by a relay. A Relay is an electrically operated switch. When an electromagnet is activated with a low voltage, typically 5 V, it makes or breaks a high voltage circuit.
Many microcontrollers have supplementary boards that attach directly to pins on their main boards. Both the Raspberry Pi and the Arduino have them. On a Raspberry Pi they are called Hats (Hardware Attatched on Top). On the Arduino they are called shields. The Raspberry Pi hats allow the main board to identify a connected hat and automatically configure the pins.
For automation systems, wired communication is preferred. The most common form of wired communication is the Ethernet, developed at Xerox PARC (Palo Alto Research Center) in 1973-4 and used ever since. Most people would be advised to use CAT 6A cable, for workshop automation.
In the future, almost every significant power tool in a workshop will be connected to the local area network, including dust collection and air filtering equipment. Even in home workshops, various variants of CNC (computer numeric controlled) equipment will be taken into use, including 3D printers and laser cutters.
Microprocessors in the 1970 would process data in a single program that ran continuously. In the 21st century, not so much. The reason for this is that each sensor (and each actuator) is treated as a separate object. Sensors publish data, about a specific state, and actuators subscribe to the data they need to make decisions about how they will operate. To do this they use a publish-subscribe protocol called MQTT. It has been around sine 1999.
PoE (Power over Ethernet)
Power over Ethernet allows electrical power to be sent over the same Ethernet cable used to send and receive data to a device. This simplifies life considerably. There are no batteries to change or high-voltage power cables to install. The main challenge is that only a few microcontrollers are capable of utilizing this feature. Using a Hat or shield with PoE connectivity is another possibility.
The California water crisis is an emblematic wicked problem. My personal awareness of the problem began in the 1950s, with the North American Water and Power Alliance proposing to divert British Columbia water to California. For many, awareness came with Chinatown, Roman Polanski’s 1974 neo-noir film. Other people were much more directly affected – having to live their daily lives in a drought-ridden California, or becoming environmental refugees.
For passionate insight rather than raw emotion, the standard work is Marc Reisner’s (1948-2000) , Cadillac Desert, 1986. With the book being over 30 years old, B. Lynn Ingram and Frances Malamud-Roam have written a worthy follow-up, The West Without Water, 2013.
Today’s weblog post is not about the California water crisis, as gruesome as it is for some, and could be for many more. It is about wicked problems. The essence of a wicked problem is that it is so complex, that it is impossible to understand all its implications. Any resolution will require a bespoke solution, which will only partially resolve disputes.
Wicked is a term used in operations research. Some practitioners infrequently or never apply it, while others use it more extensively. Regardless, many hold it with reverence. Working with these ultimate problems has the potential to elevate or destroy one’s professional reputation. More importantly, resolution of a wicked problem may positively affect the lives of millions, in some cases – such as world poverty, billions of people.
Operations research as a subject area is, itself, often misunderstood. Part of the problem is that practitioners value precision to such a degree that they find it difficult to define words. Sometimes, one suspects, their motivation is to discourage or to impress readers, rather than to clarify. In one common definition, the words advanced analytical methods appear. While most people may have a basic understanding of what method means, their understanding may be fuzzier when it comes to understanding the term analytical. Adding advanced onto that, just leaves people dumbfounded. A simpler approach is to define operations research as: the process of designing solutions to complex problems.
Wicked problems arise when operations researchers feel out of their comfort zone, which is a very numerical place. Wicked problems usually involve several groups of people, stakeholders, who see a problem from many different, and sometimes opposing, perspectives. Challenges with wicked problems often begin with finding a suitable definition of a problem and end with finding a suitable stopping point for proposed solutions. By then other related problems are revealed or created of because of complex interdependencies.
The term, wicked problem, originated with Horst Rittel (1930-1990) but was popularized by C. West Churchman (1913-2004), while both of them along with Melvin Webber (1920-2006) worked at The University of California, Berkeley. Churchman wanted operations research to take moral responsibility “to inform the manager in what respect our ‘solutions’ have failed to tame his wicked problems” ( Churchman, C. West (December 1967). “Wicked Problems” Management Science 14 (4).) Tame problems are so simple, that they can be resolved using basic mathematical and other computational tools.
Rittel and Webber specified ten characteristics of wicked problems (Rittel, Horst W. J.; Webber, Melvin M. (1973). “Dilemmas in a General Theory of Planning” Policy Sciences. 4: 155–169)
There is no definitive formulation of a wicked problem.
Wicked problems have no stopping rule.
Solutions to wicked problems are not true-or-false, but better or worse.
There is no immediate and no ultimate test of a solution to a wicked problem.
Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial and error, every attempt counts significantly.
Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
Every wicked problem is essentially unique.
Every wicked problem can be considered to be a symptom of another problem.
The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
The social planner has no right to be wrong (i.e., planners are liable for the consequences of the actions they generate).
Over thirty years later, Jeffrey Conklin (?-) generalized the concept (Conklin, Jeffrey (2006). Dialogue mapping : building shared understanding of wicked problems. Chichester, England: Wiley):
The problem is not understood until after the formulation of a solution.
Wicked problems have no stopping rule.
Solutions to wicked problems are not right or wrong.
Every wicked problem is essentially novel and unique.
Every solution to a wicked problem is a ‘one shot operation.’
Wicked problems have no given alternative solutions.
A wicked problem is so interconnected with other problems that one can’t intervene somewhere without impacting something else. It involves incomplete or contradictory knowledge, a large number of people and opinions, a large economic burden either to live with it or to resolve it.
Nancy Roberts (1943?-) identified three strategies to cope with wicked problems. See: Roberts, N. C. (2000). “Wicked Problems and Network Approaches to Resolution”. International Public Management Review. 1 (1)
Authoritative. These strategies limit problem-solving to an elite group of stakeholders, typically including experts and those with financial or political weight. This reduces problem complexity, as many competing points of view are eliminated at the start. The disadvantage is that authorities and experts charged with solving the problem may not have an appreciation of all the perspectives needed to tackle the problem.
Competitive. These strategies attempt to solve wicked problems by pitting opposing points of view against each other, requiring parties that hold these views to come up with their preferred solutions. The advantage of this approach is that different solutions can be weighed up against each other and the best one chosen. The disadvantage is that this adversarial approach creates a confrontational environment in which knowledge sharing is discouraged. Consequently, the parties involved may not have an incentive to come up with their best possible solution.
Collaborative. These strategies aim to engage all stakeholders in order to find the best possible solution for all stakeholders. Typically these approaches involve meetings in which issues and ideas are discussed and a common, agreed approach is formulated.
Before Roberts, the collaborative approach was the only one acknowledged, at least in public.
On the surface, wicked problems have a simple answer, and its name is IBIS, Issue-Based Information Systems. What distinguishes IBIS from other solutions, is that it views design as argumentation. That is, the design process requires people to reflect on the problem, deliberate, and to argue for and against different perspectives. It is also instrumental. Yes, another big word, which in this case refers to something being goal oriented. (Hulme, Mike (2009). Why We Disagree about Climate Change: Understanding Controversy, Inaction and Opportunity. Cambridge University Press.)
Computer-based versions of IBIS are available in Windows (up to version 8), Mac and Linux variants, at: http://compendiumld.open.ac.uk/download.html . While IBIS was conceived in 1968, it had to await for appropriate technology to become an effective tool. Using hypertext data-structures, the latest incarnation was implemented by Douglas E. Noble (?-).
Much social media discussion involves wicked problems, but without the poster understanding that they are dealing with such a comprehensive issue. Instead, much of the discussion may involve a very specific personal challenge, deliberately isolated from its context. From there responses are solicited, ranging from a like to a supportive comment. Yet, the response may be anything but positive. While the first poster’s position may be attacked, not infrequently there will personal attacks as well.
It is here that social media fails. It is very effective at allowing people to trumpet out problems, but does nothing to help people manage or resolve them. Where is the social media IBIS that will allow social media users to put their problems into perspective?
Social media users facing wicked problems need help to argue for their perspectives. This is very different from a vitriolic attack. They need help to structure a design problem, and to participate with others in a design solution, a process where they can reflect on that problem, deliberate and to argue for and against different perspectives, and come up with a solution that is better than the current situation.
Coming sooner or later: Russell L. Ackoff on Social Messes.
The myth of Kanban is set in the late 1940s, when Toyota began to optimize inventory levels. Several authors describe this as an engineering process. It isn’t, but myths are not invented to tell truths, but to elevate the mundane into eloquent and compelling stories. In this myth, Toyota’s goal was to align inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or kanban, between teams. When a bin of materials used on the production line was emptied, a kanban was passed to the warehouse describing the material and its quanity. The warehouse would then send a replacement to the factory floor, and their own kanban to their supplier. The supplier would then ship a bin of material to the warehouse. While the physical cards may have disappeared, Just In Time (JIT) remains at its heart of modern manufacturing.
Kanban moved from esoteric knowledge about Japanese business practices, to myth in 2010, when David Anderson wrote Kanban: Successful Evolutionary Change for Your Technology Business. The book is only incidentally about Kanban. It is more about the evolution of a software development approach at Microsoft in 2004, to a better approach at the Bill Gates owned digital image business, Corbis, in 2006-7, designated Kanban. About the same time there were several others who were name-dropping Kanban, and suggesting variations of it as a form of lean production, especially for software.
The key point with Kanban is that it works in organizations engaged in processing, either in terms of products or services. It is less applicable in organizations working on projects.
Service organizations, can establish teams to supply these services, using JIT principles. This requires them to match the quantity of Work In Progress (WIP) to the team’s capacity. This provides greater flexibity, faster output, clearer focus and increased transparency. Teams can implement virtual kanban methodology.
In Japanese, kanban translates as visual signal. For kanban teams, every work item is represented as a separate card on the board.A kanban board is a tool used to visualize work and to optimize work flow across a team. Virtual boards are preferred to physical boards because they are trackable and accessibile at every workstation. They visualize work. Workflow is standardized. Blockers and dependencies are depicted, allowing them to be resolved. Three work phases are typically shown on a kanban board: To Do, In Progress and Done. Since the cards and boards are virtual, the unique needs of any team can be mapped to reflect team size, structure and objectives.
Truthing is at the heart of kanban. Full transparency about work and capacity issues is required. Work is represented as a card on a kanban board to allow team members to track work progress visually. Cards provide critical information about a particular work item, including the name of the person responsible for that item, a brief description and a time estimate to completion. Virtual cards can have documents attached to them, including text, spreadsheets and images. All team members have equal access to every work item, including – but not restricted to – blockers and dependencies.
An important management task is to (re)prioritize work in the backlog. This does not disrupt team efforts because changes outside current work items don’t impact the team. Keeping the most important work items on top of the backlog, ensures a team is delivering maximum value. A kanban team focuses on active works in progress. Once a team completes a work item, they select the next work item off the top of their backlog.
Cycle time is the time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. This metric can provide insights into delivery times for future work.
When a single person holds a skill set, that skill set can potentially becomes a workflow bottleneck. Overlapping skill sets eliminates that potential bottleneck and may reduce cycle times. Best practices, encourage team members to share skills and to spread knowledge. Shared skill sets mean that team members can enrich their work, which may further reduce cycle time. In kanban, work completion is a team responsibility.
A kanban feature is to set a limit on the number of works in progress. Control charts and cumulative flow diagrams provide a visual mechanism for teams to see change. A control chart shows the cycle time for each work item, as well as a rolling average. A cumulative flow diagram shows the number of work items in each state. Combined, these allow a team to spot bottlenecks and blockages.
My interest in Kanban is tied to my son, Alasdair’s use of it for process management with the Council for Religious and Life Stance Communities Bergen (Samarbeidsrådet for tros- og livssynssamfunn Bergen, STLB). See: https://www.stlb.no/english/ . It is available as an app for Nextcloud, Deck. See: https://apps.nextcloud.com/apps/deck . This will be installed on our upcoming server, tentatively named Qayqayt.