Project Basics

1. Project Basics Singularity April 2014

2. Objectives • Creation of a scale software platform that covers a wide variety of commonly used operating systems • Supports WinCE6, CE7, Compact 2013, WinXP, Win7, Win8 • Supports Linux and others with minor modifications • Focus on uncompromising software quality and performance • Centerpiece is a server engine that provides • W&M approved weighing interface for all current scale technologies • All important communication protocols for common interface types • Easy to use API for application programmers (PO, MO, external)

3. Portfolio Hardware Cost Embedded Systems PC Systems 1000 USD S i n g u l a r i t y INDUSTRIAL PC WinCE / Win7 / Win8 / Linux SPECTRA 500 USD RAINBOW 100USD Low End Embedded 1 USD Performance 25 MHz 250 MHz 1 GHz

4. Portfolio • Singularity can be used for PC-based hardware like IND890 or e.g. Spectra platforms • A PC doesn't bring any weighing related software with it. Therefore Singularity can be used as full basis for the entire application through all software levels • Development teams using Spectra platforms use Spectra's hardware, DDK and ADK and are still able to add Singularity using the HMI graphical design and functional objects like scrolling, touching, wiping, SETUP etc. • This re-use of code reduces development time significantly.

5. Methodology • The team works using agile methods based on theScrumframework • The Product Owner specifies product features in small, digestible portions in the Product Backlog • These Backlog Items are reviewed every 2 weeks and selected according to their considered importance • A 2 weeks work package iscalled SPRINT

6. Methodology • The team divides the Backlog items of one Sprint package into smaller, 1 to 2 days work items called story points. • Every story point has to be reported "done" before the next story point can be checked out and worked on • DONE is specified as • Fully functional • Compiled without errors orwarnings • Implemented into the project

7. Methodology • The progress of a Sprint is discussed daily and plotted on aburn-down chart. • The burn-down chart reflects the progress within the current Sprint and gives the project manager a clear picture of the performance • The burn down chart is an excellent tool for comparing the real achieved velocity vs. the estimated required time. It allows to adjust planning quite accurately.

8. Quality • In order to make sure that the resulting software is of highest possible quality the project uses a variety of tools that make sure that every team member sticks to the strict rules • Continuous integration using • Jenkins automatically collects all new software parts and pieces on a daily basis, integrates and builds the project every night. If there are any integration faults like compiler errors, warnings or counterproductive functions, Jenkins rejects this latest piece of software and the developer in question gets an automated email message. In this case a story item is NOT DONE.

9. Quality • Another important piece of the puzzle is automatic testing. • For every new Software Class the programmer has to write a test routine which tests the correct functionality. The auto-testing is supported by MS-Test (Microsoft VS) • A very important tool is which checks, how much of the code is actually tested and reachable. The target is to have at least 80% of the entire project code covered by auto-testing. • In order to make code easily understandable and quick to familiarize, it is important for all involved parties to use the same style rules. • Same naming conventions for all classes and methods • Same code style (appearance) • Same nesting style within methods These rules are also clearly specified and automatically tested using a tool called StyleCop

10. Quality • In order to visualize the achieved quality, the team generates a number of meaningful code metrics that show the potential quality tendencies of the current software revision. • The metrics include statements about e.g. • Lines of code per Method, Complexity of Methods and others...

11. Basic Idea W&M relevant features WeightWindow, HMI Library Setup Application PO Application MO Application Customer Application Encryptedcommunication API ApplicationProgramming Interface SERVER ENGINE Center Piece  currentlyabout 400.000 linesofcode Interface drivers, scaleinterface, W&M hardwarecommunication Remote Service Hardware Abstraction Layer isolated Plug-In, just a fewhundredlinesofcode Target Hardware C Target Hardware A Target Hardware B

12. Setup BasePac Pacs / Customer App Block Diagram W&M relevant components (e.G. Weight-Window) User Interface User Interface User Interface Application Manifest Application Function Library, User Controls, Data Base API II (Client Part) API II (Client Part) API II (Client Part) Communication Interprocess- Communication API II (Server Part) Server Client Services SICS Server MMR Server? ModBus RTU/TCP (ARM100, Wago) Digitale IO Internes 4IO Autom. interface e.G. Profibus Alibi Memor ScaleIF (Local & TCP/IP) Cmmand-Filter Engine Hardware Abstraction Layer OS: Windows CE6 CE7 Compact 2013/ WinXP / Win7 / Win8 Hardware

13. Findings • Using the "agile" methodology including continuous integration, autotesting and all the other state of the art methods has proven to really dramatically increase development speed and quality • In 3 Months of development the team has achieved more functionality with an unequaled quality than it could have been done within a year's time using traditional development methods • After every Sprint, the team is able to demonstrate fully functional features. No disposable prototypes or fake gadgets. • Very fast feedback after demonstrations. The customer or cooperation partner can directly see if a required feature works the way it was intended and give according feedback • The project lives from a minimum specification. "Hard fact" individual features can be added or removed at any time to / from the Backlog List without any risk for the general scope. During a Sprint the checked out features are fix.

14. Findings • State of the art software architecture increases performance and reduces risk of fatal errors • Using Named Pipes instead of TCP/IP significantly increases communication between processes. • Using consequently asynchronous, event-triggered architecture prevents dead-loops and fatal errors

15. Findings • The current cooperation with the HMI strategy team and the SAI (standard automation interface) team have proven to be incredibly fruitful. • Sharing their specification generates a common MT look, touch and feel and prevents wasteful re-invention of code. • The excellent cooperation suggests deeper collaboration e.g. having colleagues in the US taking over the HMI software part. This way they can develop the specs and at the same time have a software platform that already uses the new philosophy. • The same is valid for the SAI team who has helped a lot finding the right hardware solution for the IND890 for Profibus, Profinet etc.

16. Current Specs / Conditions • The current scope includes a fully functional API platform for market organizations with their own programming capabilities. • W&M approved • All currently used industrial interface protocols • All currently used scale technologies except PDX (no physical interface available) • Full setup application for easy service using the future HMI design • Considering 4 100% software resources and a successful M200 end of June it is expected to be ready for an M500 end of Q1 2015

17. Open issues To be addressed for a successful M200 • Clear definition of the scope • Targeted functionality until M500 • Backwards compatibility to legacy systems – currently not planned • Frame conditions for M200 • Time frame • Resources • Financial