update docs

Author: matth-x

README.md

@@ -71,21 +71,9 @@ In case you use PlatformIO, you can copy all dependencies from `platformio.ini`
 
 ## OCPP 2.0.1 and ISO 15118
 
-**The call for funding for the OCPP 2.0.1 upgrade is open.** The version 1.6 support has successfully been funded by private companies who share an interest in using this technology. OCPP is most often seen as a non-differentiating feature of chargers and is therefore perfectly suited for Open Source collaboration. If your company needs OCPP 2.0.1, please use the contact details at the end of this page to receive the more details about the funding plan and why it is beneficial to engage in the upgrade (for hardware manufacturers and CPOs).
+MicroOcpp will be upgraded to OCPP 2.0.1 soon. The API has already been prepared for transitioning between both versions, so an integration of the current library version will also be functional with the 2.0.1 upgrade.
 
-MicroOcpp is a good foundation for starting the OCPP 2.0.1 development:
-
-:tada: Tested by hundreds, including backend operators. The [Simulator](https://github.com/matth-x/MicroOcppSimulator) encourages quick compatibility tests
-
-:hammer: Comes with development tools and a CI/CD specialized for OCPP
-
-:man_teacher: Academic background: roots in a research project
-
-:closed_lock_with_key: Unit tests with valgrind, AddressSanitizer and UndefinedBehaviorSanitizer
-
-:heart: Contributions are highly welcome. Open to building a team
-
-A note on ISO 15118: this library facilitates the integration of ISO 15118 by handling its OCPP-side communication. A public demonstration will follow with the first collaboration on an open OCPP 2.0.1 + ISO 15118 integration.
+ISO 15118 defines some use cases which include a message exchange between the charger and server. This library facilitates the integration of ISO 15118 by handling its OCPP-side communication. A public demonstration will follow with the first collaboration on an open OCPP 2.0.1 + ISO 15118 integration.
 
 ## Contact details
 

docs/intro-tech.md

@@ -80,4 +80,6 @@ Because of the high importance of C in the embedded world, MicroOcpp provides it
 
 While memory constraints are of concern, the execution time generally is not. OCPP is rather uncomplex on the algorithmic side for clients, since there is no need for elaborate planning algorithms or complex data transformations.
 
+Low resource requirements also allow new usage areas on top of EV charging. For example, MicroOcpp has been ported to ordinary IoT equipment such as Wi-Fi sockets to integrate further electric devices into OCPP networks.
+
 Although MicroOcpp is optimized for the usage on microcontrollers, it is also suitable for embedded Linux systems. With more memory available, the upper limits of the internal data structures can be increased, leading to a more versatile support of charging use cases. Also, the separation of the charger firmware into multiple processes can lead to more robustness. MicroOcpp can be extended by an inter-process communication (IPC) interface to run in a separate process.

docs/security.md

@@ -25,8 +25,9 @@ To address the challenges, the following measures were taken:
 
 Two further measures would be beneficial and could be requested via support request:
 
-- OCPP fuzzer: as a stateful application protocol, there are specific challenges of developing a fuzzer. An open source fuzzing framework for OCPP could reveal vulnerabilities and be of use for other OCPP projects as well
 - Precautious memory allocation: migrating memory management to the stack and where possible would simplify code analysis and reduce the potential of vulnerabilities
+- OCPP fuzzer: as a stateful application protocol, there are specific challenges of developing a fuzzer. An open source fuzzing framework for OCPP could reveal vulnerabilities and be of use for other OCPP projects as well. MicroOcpp is a good foundation for trying new fuzzing approaches. The exposure of the main-loop function and the clock allow a fine-grained access to the program flow and facilitating random alterations of the environment conditions. Furthermore, all persistent data is stored in the JSON format and it is possible to develop a grammatic which contains both a device status and incoming OCPP messages. The Configuration interface could be reused for further status variables which don't need to be persistent in practice, but would improve fuzzing performance when being accessible by the fuzzer.
+- Memory pool: object orientation is a very helpful programming paradigm for OCPP. The standard contains a lot of polymorphic entities and optional or variable length data fields. MicroOcpp makes use of the heap and allocates new chunks of memory as the device model is populated with data. On the upside this allows to save a lot of memory during normal operation, but it also entails the risk of memory depletion of the whole controller. A fixed memory pool for OCPP would encapsulate the heap usage to a certain address space and set a hard limit for the memory consumption and avoid polluting the shared heap area by heap fragmentation. To realize the memory pool, it would be necessary to make the allocate and deallocate functions configurable by the client code. Then appropriate (de)allocators can be injected limiting the memory use to a restricted address area. As a consequence, a more thorough allocation error handling in the MicroOcpp code is required and test cases which randomly suppress allocations to test if the library always reverts to a consistent state. A less invasive alternative to memory pools is to inject measured (de)allocators which just prevent the allocation of new memory chunks after a certain threshold has been exceeded. This programming technique would also allow to create much more fine-grained benchmarks of the library.
 
 ## Measures to be taken by the EVSE vendor