A state machine model can turn a complex behavioural system into a more accessible graphical model, and can improve the way people work with system design by making it easier to communicate and understand the system. The clear structure of a state machine model enables automatic generation of well structured, and consequently readable, and maintainable code. There are many known implementations and even plenty of commercial software available for working with state machines, and the goal of this project is to compare and discuss some of these implementations in the context of Ericsson's demands for run time, memory usage, scalability, readability, and maintainability. More specifically, the project focuses on the state machine models specified in the UML (the unified modeling language [15]), utilizing UML's associated markup language, XMI, to go from graphical model to generated C code. The resulting C code is primarily a code skeleton which only provides the basic behaviour of transitioning between states given a specific event, it is expected that the developers manually implement additional features themselves. The examined implementations are: Nested Switch, Array of Structs, Function Pointers, Basic State Pattern, State-Table Pattern, and Hierarchical State Pattern. Additionally, the project investigates how multiple state machines can communicate and work together as interacting state machines. And finally, to showcase how a state machine implementation can be maintainable, we develop an iterative code editor that can edit already operating and manually modified state machine implementations. The implementations are tested on a case study example provided by Ericsson, aimed to represent a sort of typical state machine design when it comes to number of states and events. The implementations are further tested with randomly generated state machines, to examine their scalability properties. In our opinion the results favour the Array of Structs and Basic State Pattern implementations and the choice depends on the optimisation used and the priority between run time and memory.