Blogg | Combine

# Blogg

#### Introduction

One of the things that has been always drawing my attention is the automated
vehicular control strategies and how they could reshape the transport sector
dramatically. One of the methods that many automotive manufacturers have
been recently developing is what is called platooning. A platoon is a convoy of
trucks that maintains fixed inter-vehicular distances, as shown in the Figure 1,
and usually applied on highways.

Figure 1: Trucks Platoon

The advantages go beyond the driver’s convenience and comfort. Having a lead
truck with a large frontal-area would reduce the air drag force acting on the
succeeding vehicles. Therefore, the required torque to drive the trucks at cer-
tain speed will be decreased which lead to less fuel consumption. That means,
of course, less CO2 emissions and lower financial burdens.
However, in a single-vehicle level, there is another approach that has been inves-
tigated for a better fuel economy. This approach utilizes the future topography
information in order to optimize the speed and the gear for a vehicle travelling
in a hilly terrain by exploiting the vehicles’ potential and kinetic energies stor-
ages. In this approach the velocity will vary along the road depending on the
platooning approach in which vehicles maintain almost the same speed along

#### HOW TO HANDLE IT?

A combination between these approaches could be implemented using the model
predictive control (MPC) scheme. Since there are many process constraints,
such as inter-vehicular distances, engine maximum torque, road velocity limits,
etc. MPC is a perfect candidate to handle these constraints especially that in
many cases the system will be operating close to the limits. The control design
could be handled in two approaches, the centralized control design and the
decoupled control design. In the centralized controller, as shown in the Figure
2, all the vehicles’ private data such as mass, engine specs, etc. in addition to
their states such as velocity and time headway are sent to the central predictive
controller via vehicle to vehicle communication, could be in one of the trucks
probably the lead vehicle or even in a cloud. One of the methods used for optimal
control is the convex quadratic programming problem (CQPP) in which every
local minimum is a global minimum. The problem is as follows

$$min\,z = f_0(x) \\ f_i(x) \leq 0 \\ Ax = b$$

Where f0,f1,f2, …, fm, is the objective function, and the inequality constraints
are convex functions. However, the equality constraints are affine functions.
In the platoon case, some convexification is needed in order to get CQPP. Hense,
the problem is solved and the optimal speed and time headway references are
sent back to the vehicles’ local controllers. This approach optimizes the fuel
consumption for the whole platoon rather than individual vehicles in which the
group interest comes first. One of the drawbacks of this approach is that in order
to solve the problem you need to handle huge matrices since all the vehicles info
is handled at once. In other words, this approach is rather computationally
expensive.

Figure 2: Centralized adaptive cruise control

The decoupled architecture, as depicted in the Figure 3, could be a solution for
ming (QP) problem for the whole platoon, each vehicle considers itself, which is
why called greedy. The problem starts to be solved from the leading vehicle and
goes backwards. Each vehicle solves the QP, considering the gaps in front of the
vehicle and the road topography, and sends states to the succeeding vehicles.
The pros of this approach are that trucks need not to share their private data
and the matrices sizes are much smaller. So the computation time is less than in
the greedy control strategy but the solution is not as optimal as the centralized
controller.

Figure 3: Greedy approach

#### CHALLENGES

As it is mentioned above, formulating a convex quadratic programing problem
is used to get the fuel-saving velocities. Since the vehicle dynamics are quite
nonlinear, linear approximations are needed, therefore, finding an appropriate
velocity reference is essential, assuming that the vehicle will be driven close
to the reference. Finding such reference should consider many factors such as
maximum traction force along the road, road limits and the cruise speed set by
the driver. One of the other challenges is gear optimization which could be solved
using dynamic programming. The complexity of dynamic programing problem
increases exponentially with the rise of the vehicles number, as a result, the
problem become computationally demanding, therefore, it is not very reliable
for the real-time implementation.

The simplest diagnostic example would basically consist of two sensors y and z, which are measuring the same unknown quantity x. When considering that the sensor-values could include errors, f1 and f2, the resulting system become:

y = x + f1                           (eq. 1)
z = x + f2                           (eq. 2)

As x is the only unknown variable, this system of equations is overdetermined.
This enables the construction of a residual, that is a connection between known quantities that are equal to zero in a fault free scenario. Residuals are usually denoted with r, which in this case results in the following residual:

r = z – y = f2 – f1

The residual r has the possibility of detecting the physical faults f1 and f2, but there is no way to determine which of the faults that has caused r to deviate from zero. The ability to pinpoint which fault has caused the deviation is known as the isolability of the system. By adding a third equation to the system, full isolability is achieved.

u = x + f3                           (eq. 3)

r = z- y = f2 –f1
r1 = y – u = f1 – f3
r2 = z – u = f2 – f3

It is however possible to create residuals through which all 3 faults are detectable by combining all three equations, e.g.

r3 = z – 0.5y -0.5u.

This residual does not contribute any additional information compared to the information already given by r, r1 and r2, which follows from which equations that were used to create each residual.

{E1, E2} resulting in r                   (set 1)
{E1, E3] resulting in r1                 (set 2)
{E2, E3} resulting in r2                 (set 3)
{E1, E2, E3} resulting in r3           (set 4)

What differs the top 3 sets from the bottom one is that the top three are what is called Minimal Structurally Overdetermined sets of equations, also known as MSOs. The minimal part corresponds to an MSO not being a subset to any other overdetermined set of equations. Set 2 is a subset of set 4 for instance, but not vice versa. The structural nature part of MSOs enables analysis of very complex systems as it only takes the existence of unknown variables and faults into account and not in what way these are included into the equation. For example, equation 1 would structurally be summarized as x and f1 exist. For a system of equations, this can be plotted by using a matrix, where each row corresponds to an equation, and each column represents existence or non-existence of faults or unknown variables. This is called the Dulmage-Mendelsohn decomposition.

For additional information regarding computing MSOs, see Fault Diagnosis Toolbox on github. One interesting application of residuals is model validation. This application is possible due to the fact that if a model is correct, the residual value is likely to be low and vice versa.  If a model has a low accuracy, it is often of interest to pinpoint the low accuracy to a particular subpart of the model, if it is possible. This can be achieved by letting the faults {f1, f2, f3} represent model equation errors {fe1, fe2, fe3} and then generate residuals based on MSOs.

By using as few equations as possible in each residual, maximum isolability regarding model inaccuracy can be achieved. One method used to convert residual-values to one metric (in order to compare the validity of different model equations) is to compute the mean-values for all residuals sensitive to a specific fault fex, and then multiply these means together to a single value R_fex. The absolute value of R_fex doesn’t provide much information, but by comparing R_fex to values generated through residuals that are sensitive to other faults (fey, fez,..) an indication of model accuracy is achieved.
R_fe1 > R_fe2 -> equation 1 is likely of lower accuracy then equation 2.

For further information and examples on bigger models see (Karin Lockowandt, 2017, p.30).

ODF will be an arena to build competence and nurture innovation. It is open to all who believe that crunching data from the ocean is first of all fun, secondly, holds the answers to a sustainable blue economy and, thirdly, gets really productive when different competencies work together! Data collected from the ocean poses challenges such as numerous data sources with varying characteristics and time scales, communication difficulties and harsh environment for the sensors which can lead to poor data quality. Overcoming these challenges using efficient AI will be vital for the future of the blue economy and sustainable ecosystems.

ODF will be headed by professor Robin Teigland from Chalmers University of Technology. SCOOT (Swedish Centre for Ocean Observing Technology) takes on the coordinating role. Stay tuned for more information in the future.

ODF is part of Vinnova’s investment to speed up development within AI.

#### Introduction

The issue of deep learning (DL) is a hot topic in modern society and is one of the most rapidly growing technical fields today. One of many subjects that could benefit from deep learning is control theory. Its nonlinearities enable implementation of a wider range of functions and adaptability to more complex systems. There has been significant progress in generating control policies in simulated environments using reinforcement learning. Algorithms are capable of solving complex physical control problems in continuous action spaces in a robust way. Even though the tasks are claimed to have real-world complexity it is hard to find an example of such high-level algorithms in an actual application. Moreover, we have found that in most applications in which these algorithms have been implemented, they have been trained on the hardware itself. This does not only enforce high demands on the hardware of the system but might be time-consuming or even practically infeasible for some systems. In these cases, a more efficient solution would be to train on a simulated system and transfer the algorithm to the real world.

Furthermore, one might wonder if a traditional control method would perform better or worse on the same system. In order to recognize how well the deep learning algorithm is actually performing, it would be interesting to compare it to another method on a similar control level.

The main purpose of this project was to provide an example of a fair comparison between a traditional control method and an algorithm based on DL, both run on a benchmark control problem. It should also demonstrate how algorithms developed in simulation can be transferred to a real physical system.

#### Design

Due to its unstable equilibrium point, the inverted pendulum setup is a commonly used benchmark in control theory. There can be found many variations of this system, all based on the same principal dynamics. An example of this is a unicycle which principal dynamics can be viewed as an inverted pendulum in two dimensions. Thus, as a platform to conduct our experiments, we constructed a unicycle.

Figure 1: CAD model of the unicycle

Our main focus for the design was to keep it as lightweight and simple as possible. To emphasise the low hardware requirements, we chose the low-cost ESP32 microcontroller to act as the brain of our system. On it, we implemented all sensor fusion and communication to surrounding electronics necessary to easily test the two control algorithms on hardware. We dedicated one core specifically for the two control algorithms and added a button to switch between the two algorithms with a simple press.

To be used in simulation and control synthesis, we derived a nonlinear continuous-time mathematical model using Lagrangian dynamics. The unicycle is modelled as 3 parts, the wheel, the body and the reaction disk, including the inertia from all components in the hardware. It has 4 degrees of freedom; the spin of the wheel, the movement of the system, the pitch of the system and the rotation of the disk. The external forces on the system come from the disk and wheel motors.

#### Controller Synthesis

The infinite horizon linear quadratic regulator (LQR) is a model-based control problem which results in a state feedback controller. The feedback gain is determined offline by from an arbitrary initial state minimizing a weighted sequence of states and inputs over a time horizon that tends towards infinity. The LQR problem is one of the most commonly solved optimal control problems. As a mathematical model of the system is available and due to its characteristics, we implemented an LQR controller for this project.

For our deep learning control of the unicycle, we chose proximal policy optimization (PPO). The method is built on a policy-based reinforcement learning which offers practical ways of dealing with continuous spaces and an infinite number of actions. The PPO has shown superiority in complex control tasks compared to other policy-based algorithms and is considered to be the state-of-the-art method for reinforced learning in continuous spaces.

To make a long story short we trained the algorithm for the system by writing up the mathematical model of the unicycle in Python as an environment for the agent to train in. The actions the agent can take are the inputs to the two motors. After taking an action it moves to a new state and receives a reward. After some millions of iterations of taking actions and receiving rewards the agent eventually learns how to behave in this environment an creates a policy to stabilize the unicycle.

#### Results

Both methods successfully managed to stabilize the system. The LQR outperformed the PPO in most perspectives in which the hardware did not limit the control. As an example, in practice, the LQR managed to stabilize from a maximal pitch deviation of 28 degrees compared to the PPO method which managed 20 degrees. We observed this sub optimal behaviour of the PPO in several situations. Another example can be seen when applying an external impulse to the system.

Figure 2

As can be seen, the LQR handles the impulse in a somewhat expected way while the PPO goes its own ways.

This unexpected behaviour is not desirable for this system but we think it might be seen as beneficial for other systems. For example, systems with unspecified or even unknown optimal behaviour. However, for systems with a specified known optimal or expected behaviour, we would recommend the good old LQR, if applicable.

Even when exposed to model errors, the PPO did not show any sign of unreliability compared to the LQR in states it had encountered during training. However, when introduced to unknown states, the performance of the PPO is impacted. By keeping the limits of the training environment general enough this should not be an issue. However, when dealing with systems with large or even unknown state limits, LQR is probably a safer option.

We believe our project has shown a good and fair comparison between these two methods on the same system as well as has given a good and informative example of how a DL algorithm trained in simulation can be transferred to a real physical system. The unicycle is of course only an example of such a system, but we feel like we encountered a lot of interesting features that can be generalized and used to benefit other projects. If you have doubts, please read our report!

“The cloud” or properly referred to as “Cloud Computing” is a general term used when talking about computations or data storage on a server at another location accessible through an internet connection, i.e. “in the cloud”. Hence the computation is not made on your local computer nor on a local server.

The area of use for cloud computing has primarily been within data/file storage and offline computation, whereas the use of online computation is currently on the rise. It is particularly strong within the field of data science which looks at large amounts of data to get insight and retrieve relevant information for taking appropriate decisions. This is one of Combine’s specialty areas and our open-source tool Sympathy for Data and its cloud companion Sympathy Cloud. https://www.sympathyfordata.com

#### Connected services within the automotive industry

An area where online cloud computation especially is on the rise is within the automotive industry. Because once one automotive manufacturer delivers functionality within a new growing area the race begins, and it has officially started. Some of the key players so far are:

#### How it works

One application of the cloud within the automotive industry is to keep track of the location of all connected vehicles at any time and assess whether a particular vehicle requires information for its current trajectory. This information could, for example, be of informative or safety critical character or crucial for the driver/vehicle to plan ahead.

The assessment is broken down into localization, trajectory estimation and translation of everything to the same timeframe. Depending on where you put the responsibility of the final assessment, you could either have the cloud make the complete assessment or have the necessary information be sent down to the intended vehicle for final assessment through onboard data processing.

The main application for this technology so far has been within the information flow to the driver of potential safety threats along the road ahead, such as hazardous obstacles (broken down vehicles or road work areas) or ambient information (road friction). But by introducing cloud-to-cloud communication, where for example one cloud can hold infrastructure information (such as traffic light information), the spectra of information are broadened.

However, the main benefit of using the cloud would come by having this as a “mother of all sensors”-sensor, i.e. by being able to receive data of your surrounding which is statistically substantiated. It would then be able to assist in reaching level 5 automation for autonomous driving vehicles (https://www.gigabitmagazine.com/ai/understanding-sae-automated-driving-levels-0-5-explained).

The main challenges on reaching there are:

• Latency; as it is a real-time system, the latency of both, communication as well as computations, are crucial.
• Computational reliability; as always, the computational reliability is crucial, but when being within an online cloud computation framework the information sent to the vehicle needs to be fully reliable to be able to relentlessly act on it.
• Having enough data; both having enough data from a vehicle to assess a situation but also having data from a sufficient number of vehicles.

#### The future of online cloud computing

As internet accessibility is getting better and data transmission is getting cheaper, especially with 5G on the horizon, the future of online cloud computing looks promising. If more and more companies go towards data sharing, the range of possible applications looks even more promising.

Nevertheless, the main issue when collecting and sharing personal data (such as vehicle data or data from your mobile phone) in such quantity and quality, will, however, be integrity. Sharing and storing data continuously at every instant will open the door to misuses such as surveillance or tracking, no matter how anonymized the data may be. And thus, we are moving towards an “all-seeing eye” society.

Kickstarted by the need for portable electronics such as phones and laptops and fueled by the increasing demand in storage capacity, battery technology has seen unprecedented improvements over the past decade.  Nevertheless, even the most advanced battery types share a common trait – they degrade over time, decreasing the amount of potential energy (or capacity) they can store. After they drop to about 80 % of their nominal capacity – typically after several thousand cycles – they are considered at the end of their so-called remaining useful life (RUL) and usually discarded. But the end of RUL does not have to mean retirement. Batteries are prime candidates for second-life applications in systems featuring lower requirements, stationary applications or auxiliary units. But how can we determine how long the battery has left until absolute failure? After all, any investment in cycling applications requires a safe assessment of remaining capacity and projected degradation trajectory. Enter another promising field experiencing rapid growth – machine learning.

One can argue that the most crucial part of machine learning is acquiring wellannotated data. Even the most complex model will not be able to make sense of a dataset that is too small, missing key variables or of poor quality. Without good quality data, the model choice or parameter tuning is of little importance. The team behind ”Data-driven prediction of battery cycle life before capacity degradation” (Severson et al., 2019) provides an extensive dataset monitoring battery degradation. In their paper the authors claim the dataset to be the largest publicly available dataset so far, containing close to 97,000 charge-/discharge cycles of 124 commercial LiFePO4 battery cells.

During the charge-/discharge cycles, the team continuously monitored voltage, current, temperature and internal resistance of the batteries. External factors influencing battery degradation were limited during the data generation process by performing measurements in a temperature-controlled environmental chamber set to 30 °C.  The batteries were subjected to varied fast-charging conditions to facilitate different degradation rates while keeping identical discharge conditions.

In the feature engineering process, the authors found a single feature to have a linear correlation factor of -0.92 with the log of RUL. This feature was the log of the variance of the difference between discharge capacity curves, as a function of voltage, between the 100th and the 10th cycle. Thus, the engineered feature could be used by itself to achieve great prediction results of RUL after the 100th charge/discharge cycle.

Using Elastic Nets, with default parameters, we obtained the following prediction results after the 100th cycle.

Note that we decided to use the first cycle as a reference when creating the feature instead of the 10th suggested in the paper. Next, the degradation of five (randomly selected) individual batteries is shown together with their predicted RUL. Its exact value is difficult to predict correctly but may be of sufficient precision for simple classification tasks.

While the engineered feature used has an outstanding correlation with RUL it is nevertheless very restrictive. Using such a feature basically means performing 100 charge/discharge cycles in a controlled environment before a prediction is possible. In a commercial setting, such a setup will be too time-consuming, costly and thus impractical. Therefore, finding other features that are less restrictive but still offer good predictive performance is important. For example, we found that using the first cycle as a reference instead of the 10th is a suitable candidate for predicting RUL, increasing the commercial viability of the prediction method. The figure below visualizes the correlation coefficient between the feature and RUL for each cycle up to 200 cycles.

The figure tells us that the linear correlation is the largest around 100 cycles. It might still be possible to use the feature already after 40-50 cycles with a smaller reduction in performance. Keep in mind that this is the linear correlation most indicative of prediction performance for linear machine learning methods, while non-linear methods can find useful information for prediction even though the linear correlation is low.

Until now, we have only considered one feature for predicting RUL, but several more can be engineered from the charge-/discharge cycle data. Introducing more features leads us to another problem, namely, feature selection. There are regression methods that can report on the feature importance for prediction following their training. An example of such a method is the Random Forest Regressor (RFR), which is also a non-linear estimator. Supplied below is an example of feature importance an RFR after fitting.

Using the smallest subset with a joined total importance of more than 0.8 the top 6 features were selected and the following prediction chart was obtained on test data.

As can be seen, the predictions are the best when the RUL is smaller than 200, but between 250-1500 the mean prediction is close to the RUL at the cost of increasing variance. Only half of the battery cells live longer than 850 cycles, which decreases the amount of training data for larger RULs and will introduce a bias towards better predictions for smaller RULs.

The eager reader might be wondering about the elephant in the room by now – what about actual batteries? After all, they would be the focus of any real battery lifetime prediction efforts. The discussion above, however, has considered individual cells, tens or even hundreds of which are usually combined into battery packs to obtain the necessary voltage and current in commercial applications. Unfortunately, no public dataset of the same magnitude as the Stanford study is available. As a stopgap measure, we can construct a collection of virtual batteries by simply aggregating the cells to mimic existing products – e.g. a 72Ah LiFePO4 pack. This method is akin to bootstrapping, in this case choosing 68 cells with replacement from the dataset to obtain a collection of training and testing packs. It is also a poor approximation of reality, since it does not model any of the possible complex interactions within a pack. It thus servers more as a preview of possible future studies. We can then train a Random Forest Regressor on the whole lifetime until failure of the training selection and predict RUL of the testing collection. The figure below presents the resulting predictions in orange against the blue RUL lines of five selected packs, showing not only their striking similarity but also a high accuracy of our predictions ($$r^2$$ ≈ 0.99). It serves as a depiction of our main idea – by aggregating the cells together we effectively “smooth” over their individual impurities, removing uncommon outliers and thus enhancing the predictive capabilities of our model.

Of course, the applicability of this approach needs to be tested extensively against real-world battery health data. Gathering and analyzing it will be the next exciting step on our journey and our contribution toward saving the world. After all, we wholeheartedly agree with Mr. Anderson, and humbly add – the future is electric or not at all.

AiTree Tech, together with Combine, is eager to help contribute to a better environment and a sustainable future. While many actors are focusing on today’s transfer of energy source from fossil fuels to batteries, we try to look ahead and are focusing on how to reuse batteries after their 1st and 2nd life.

ENTER THE NEXT LEVEL

AiTree technology is providing a data driven machine learning solution with the purpose to predict lithium-ion batteries (complete) lifetime from 1st life to end of life.
Let’s start the journey togheter!

Johan Stjernberg CEO@ AiTree Tech
+46(0)733 80 08 44

Erik Silfverberg CTO@ AiTree Tech
+46(0)730 87 40 20

### The Problem

The problem that arises is that a company is not any longer capable of handling or analysing the amounts of data with its standard laptops and methods. The obvious limitations come for a hardware perspective, the data is often too large to be stored on a hard drive and most definitely cannot fit into the RAM, or the CPU is too slow and computation times grow easily to hours if not even days for even the simpler tasks. The limitations of the used software are something which quite often is overlooked. Throwing more computational power at the problem seems like the best solution, but optimizing the framework used to handle the data might be just as important, if not more, to increase performance.

#### Solving the Problem

So what do you do when you can no longer analyse the data yourself? Many companies have resorted to using cloud services. These services use a cluster of computers or servers, basically renting out hardware capabilities as the customers need it. This is a neat solution with a low threshold for individual companies and maximizes the usage of the hardware. It does not come without its drawbacks though. Data security is the first thing which comes to mind. Your confidential data needs to be uploaded to servers which are out of your control, and while the providers of cloud services are without a doubt very serious about safety, the security of the data is now out of your hands. Secondly, if you need serious hardware capabilities, such as a CUDA compatible GPU for deep learning, the prices quickly increase and grow larger than the value it brings. Lastly, to access the services and work with your data, you need connectivity. Downtime is not uncommon and in these time periods, you are not able to do your work. So what is the option? To ensure the security of your data, minimize costs, and maintain the possibility to work even if internet connectivity is down the solution is to bring the Big Data capabilities in-house. Choosing the correct hardware is, of course, an important decision and a whole topic on its own, but picking the appropriate software and frameworks is equally important, there is no use in having bridged CUDA GPUs if you cannot use them, or 100 CPU cores if you cannot support multi-threaded  computations.

#### Python Tools

Python, along with R has for many years been a very popular choice for data scientists around the world, it has many different toolboxes which makes working with data, and producing interesting results easy, plus it is not proprietary software. So if you want to use Python for your in-house server, what different Big Data tools are at your disposal? The favourable tool which is used widely nowadays is Pandas. But as we will see later, this might be about to change.

#### Pandas

Pandas is described as open sourced, high-performing, easy-to-use data structures and analysis tool for Python1. It provides ready-built functions for reading, writing, selecting, and analysing data in a compact and intuitively way.

#### Accelerator

Accelerator, an open sourced python library, is a data processing framework that provides fast data access, parallel execution and automatic organization of source code, input data and results2. This tool focuses on performance rather than simplicity and user-friendliness. You do not need to be a programming wizard to use it, but the ready-built functions are more sparse. Comparison of Pandas vs Accelerator So let us put the well-proven, easy-to-use tool of Pandas head to head with the performance-driven
Accelerator. The first thing you need to do in any project with data is to read it from the disk. Pandas supports reading of several different formats, but csv and excel files are the most common. Accelerator has its own  dataset class. We create some dummy data containing two variables and n rows. We use the built-in function to read csv file in Pandas, and the Dataset class in Accelerator, once loaded, we iterate over the data once.

Figure 1: Reading data from disk and iterating over all rows

We can see that as the size of the dataset grows, Pandas is starting to take a lot more time compared to Accelerator, note the logarithmic scales on both axes. Reading from disk is notoriously slow, so let us ignore the reading time for Pandas and look at just the time to iterate over the rows. Accelerator is made for super fast reading and writing to disk, and does not load all the data into memory in the same way as Pandas, therefore we will keep the time reported for Accelerator as the time it takes to both read
the data and perform iterating over the rows.

1https://pandas.pydata.org/
2https://www.ebayinc.com/stories/blogs/tech/announcing-the-accelerator-processing-1-000-000-000-lines-per-secondon-
a-single-computer/ Figure 2: Pandas: Iterate over all rows, Accelerator: Read data and iterate over all rows

We see that the time it takes to only iterate over the rows is less than read plus iterating for Pandas, but Accelerator is still able to both read the data and iterate over all rows faster than Pandas with growing data size. Let us have a look at some of the most commonly used statistics which has built-in functions in Pandas, starting with the summation of all rows. Here we calculate the sum of all rows for the two variables in the dataset. We will have a look at both the total time for reading data and calculating the sum and only the calculating the sum part for Pandas, while for Accelerator we only report the time for reading data plus calculating the sum to get an idea of how the built-in functions of Pandas perform alone, and how it would compare in a more real-life situation where the data has to be loaded as well.

(a) Pandas: Read data and sum of two variables, Accelerator: Read data and sum two variables (b) Pandas: Sum of two variables, Accelerator:
Read data and sum two variables

Figure 3: Summation of variables

In this case, Pandas is actually faster (even if just slightly) even with one billion rows of data when not taking into account reading the data. If the data has to be read from disk first, Accelerator is still much faster for larger datasets. Let’s look at two other built-in functions of Pandas. First, selecting or filtering of rows, in this test we select all rows where the first variable is larger than a set value and discard all other rows. In the second test, we multiply the two existing variables and create a third variable containing the result. Again, for Pandas, we look at both the time it takes to only do the relevant calculation and reading plus performing the relevant task, and for Accelerator, we look at the time for both readings and performing the relevant calculations only.

(a) Pandas: Read data and filter data, Accelerator: Read data and filter data (b) Pandas: Filter data, Accelerator: Read data and filter data

Figure 4: Filtering of data

In these tests, Pandas is faster as well when the data has been previously loaded. Here we are able to see the high-performing aspect of Pandas. The built-in functions Pandas provides are actually fast and efficient, but in a full-scale data science project, it might still not be enough. The first issue which might make Pandas not suitable for a project with very large amounts of data is the data reading. By performing much analytics in the same script and reusing data, it is possible to minimize the number of times the data needs to be read from disk. But in reality, scripts will have to be re-run many times because of bug fixes, changes in plots etc. For readability and version control it is also undesirable to have one large script that performs multiple analytics, and as such it will be quite impossible to not have to read the data from disk often. Secondly, while the built-in functions of Pandas can do many things, they are still limited. Out in the real world, the data is rarely structured in a perfect and intuitive way, and statistics such as means and sums cannot be done in the traditional way, resulting in having to create a custom made solution which requires iteration over all the rows which as we saw is significantly slower in Pandas.

#### Final Thoughts

In these tests, we have seen that the built-in functions of Pandas are in fact fast and efficient, but reading the data from disk and manual iteration over the rows quickly becomes quite slow in comparison to Accelerator which is able to do all the different things in a more consistent time. Pandas has many strengths and will definitely remain one of the top choices when working with data in general, but for projects with datasets with more than some tens of million rows, Accelerator will provide faster  development and calculation speeds. In projects with smaller amounts of data, or pilots projects when not the entire available dataset is used, the easy-to-use Pandas framework is still preferred in general, but for the larger scale Big Data projects, Accelerator will be the obvious choice.

Who are you?
My name is Charlie Sjödin. After working for two years at a large consultancy firm I felt that something was missing. When I started looking for new opportunities and I came across Combine, where Thomas (former group manager for Control Systems Solutions Gothenburg) was lurking in the shadows. It was in April 2017 when I started working at Combine and have since worked on an assignment in connected safety at Zenuity.

You have just recently arrived back from a leave of absence. How have the past months been?
Yes, that is correct. I arrived back to Sweden in the beginning of April after a long and well needed leave of absence during which I have been travelling abroad in Southeast Asia. During the 5 months of travelling through Thailand, Laos, Indonesia, Vietnam and Cambodia I saw both beautiful nature, crazy traffic and tasted a lot of amazing food. Everything from excellent curries (and cricket-snacks) in Thailand and Cambodia, Sambal-infused dishes in Indonesia to crispy spring rolls in Vietnam.

The plan for the trip from the beginning was to have time to experience the countries as they are; their rich culture, people and nature. Unfortunately, the reality caught up to me quickly as the infrastructure was poor and travelling by public transport took much more time as anticipated. However, I was still able to visit all the countries, got to know the people and indulge in their culture, even though a bit more touristy than planned.

Some of the most memorable experiences from the trip were the karst limestone cliffs in Bai Tu Long Bay (Vietnam) and the Bayon temple in Angor area (Cambodia). Just search on the interwebs and be wowed.

With so much new experiences and time to think, is there a reflection that you find especially interesting that you want to share?
Absolutely. One reflection I made from the trip is the responsibility for us engineers in making conscious moral choices. Maybe this is not valid on on a daily basis, but in our overall contributions to the development of the world certainly plays a role. Just think about the importance of the complete lifecycle of a product. A main issue I saw during my trip was the negative impact of neglecting the lifecycle of different products and its impact on nature, where plastic waste is undoubtedly one of the more extreme example. Also the accident of the Boeing 737 plane, crashing in Indonesia, illustrates the important role of an engineer for delivering safe and well-tested software black on white.

So, you are back with new experiences. Where do you see yourself taking the next step in your professional life?
As a newly enlightened environmentalist, I would like to contribute to the sustainability of this world. Whether this will be within the automotive industry or another industry, is for now shrouded in mystery as we are looking for a new assignment.

The history of Sympathy for Data
The founders behind the Platform were two employees at Volvo Cars, Stefan Larsson and Krister Johansson.

In August 2009 Stefan Larsson started writing the first prototype. The prototype was presented to his colleague Krister Johansson, a technical expert in statistics, who also worked at Volvo Cars. Krister immediately realized the potential of the concept and started to assist in finishing the prototype.

By December 2009 they came to the insight that it wouldn’t be possible to finish the software while still having a day time job. They decided to ask for permission to continue work during work hours under the condition that the ownership of the software was put in a non-profit organization and was published using an open source license. Krister and Stefan continued programming and started preparing for the founding of the non-profit organization.

In May 2010 Krister and Stefan set up a meeting with Combine. Combine became interested in the concept and in December 2010 the non-profit organization “System Engineering Software Society” (SysESS) was founded.

Since then Combine has led the development of Sympathy, with Erik der Hagopian as Product Owner, with the purpose of providing an open source solution in the domain of Data Science.

The intention in the long run
Combines intention is to continue licensing Sympathy for Data as an open-source tool. However, add-on products such as cloud services, cluster support, etc will not be licensed under an open-source license. Neither will we try to build another BI-tool, but continue to develop the kind of functionality that makes Sympathy great.

Future functionality
We see the need of developing such functionality as streaming support, cluster support, cloud services, the ability to handle huge amounts of data using a better/smarter backend as well as a need to focus more on user experience.

The next chapter
We now start the next chapter for Sympathy where we aim to increase the development pace of functionality mentioned above as well as focus on Machine Learning, Deep Learning, Image Processing, etc.

Enter the Next Level!
Erik Silfverberg
CEO, Combine Control Systems AB

Shaping the future
The environmental impact of electric cars, and to be more specific, the batteries used in those cars are constantly under scrutiny. One possible solution is the reuse of vehicle batteries, often called second-life. The concept enables repurposing batteries that no longer meet the requirements of their intended vehicle application but still fulfil those of other applications.

Circular economy
The battery of an electric vehicle is today considered to have reached its “end-of-life” when its capacity decreased by approximately 20-30% compared to the initial value, which means that 70-80% of the capacity remains.

The problem today is to determine if the battery could be reused or if it should go to recycling?

Once we can determine the “end-of-life”, the batteries could easily go into the concept of circular economy, minimizing the use of our precious resources. By utilizing circular economy we can reduce cost, for example by re-selling batteries in an energy storage system or recycling them for reuse in a battery factory.

AiTree Tech will provide a data driven machine learning solution. The aim is to predict the (complete) lifetime of lithium-ion batteries from first life to end of life.

The solution will enable customers to:

• understand the scenario of re-manufacturing
• analyse data and optimise the battery size depending of its usage
• get a better understanding of the lifetime (1st, 2nd life, etc.)
• get ID tracking for reporting to authorities

The company will be up and running during 2019.
Let’s contribute to save the world!

Erik Silfverberg
CEO, Combine Control Systems AB