As Cloud is now released, we wan’t to give a quick heads up on whats planned for coding.

First things first. Our cloud app is not just like any other PHP portal that requests files from an API and stores them, it is more than that. Internally, the data structure is already prepared for coding and anything else that is to come and is on our road map. The vision is to store any requested file, and later uploaded file, that relates to a specific car. Each of those (mostly) can be used to run advanced tasks. For example, an vehicle order will be able to be used for generating an SVT in our system. The generated SVT can be used to plan a retrofit and check which ecus have to be exchanged by which specific part number so the retrofit will be successful.

Maybe its best summarized by: Our application will act like a simplified native Esys installation but the generation and interpretation of data will be done by our servers and do not have to be done by the user plus data is enriched by information that is normally not available to the end user. Also, tools that weren’t in Esys, will be added to our cloud tools. Like we already added the FSC generator for Champ2/CIC/NBT/NBTEvo ID4 and EntryNav.

We want to make anything around coding, FSC generation or working at BMWs in general as easy as possible. Not only for experts that know how to use Esys but also for beginners and coders, that use our tool only for their private car. Yes, most coders will say: i can do everything myself, i do not need that. But more than half of the support requests were more or less simple tasks that are part of Esys instead of an EsysX feature and we had to explain that – for most people – basic knowledge.

EsysX’s (IspiHost) FSC generator is dependent on a server connection. The servers that are running behind EsysX are not in our control. Our lost team member changed server deployment and we weren’t aware of that. We called the provider but couldn’t get ahold of any information. The only thing we got from them is an account number, that we can keep sending money to so the server keeps being alive and that is what we are doing since then. But this also means, that if the server stops due to a runtime exception, we aren’t able to restart them.

So that is the point why we identified that part as a high risk and therefore first priority to implement so we can move our EsysX FSC Gen users over to the new app if anything happens. This implementation also gave us the opportunity to get the base backend implemented with credit system etc. so basically the features we would have needed for anything else to come anyway.

So if, at anytime, the EsysX FSC Gen is not available, please get in contact, you will get all the credits from that generator in our new system as soon as an account is created.

So besides the FSC generator, the other functions have been implemented because they were already existing and it was more or less a rather easy task to get them working in the new environment.

Implementing EsysX with all its security measures was a time consuming task. It took more than the half of time to get and keep EsysX secure than for implementing any Expert feature. This lead us to the idea to store files in the Cloud so not any mapped CAF is available on the users system. Re-implementing EsysX would not have been possible and would have taken years! So that was no option for us.

In the automotive sector, it is a common feature to prepare coding for cars in development then saving them on the PC for later (offline) use. That’s the direction we want to go. Here are the steps in which we want to implement the coding feature:

1. Implement a coding and mapping engine in the cloud. Users shall be able to select any CAF with or without uploading it and change them in our cloud app, then generate an NCD which can be coded with any Esys version, not just ours. The NCDs are assigned to the virtual car and act as a backup. So ideally you could switch between codings within seconds.
2. Develop a modified Esys version which connects with our backend and requests all prepared files for a specific car. Users shall be able to right click an SVT CAF node then select a prepared coding file (stored on our server) and click “code”.
3. Implement the possibility to download coding data before working on a car so the actual coding can be done offline…

We haven’t evaluate those options to a full extend so they are indeed subject to change, but that’s what we see as the future for our application. This will also enable us to sign coding data on the fly. It will be needed for secure coding anyway so as soon as that is in place, people will have to work online, be it with native Esys or with EsysNeXt.

We will also be able to update mapped data within seconds and for all users concurrently. So we do not have to ship out dozens of licenses on request.

As we released Cloud, most people expected coding to be available. This led to lots of non-constructive feedback which we couldn’t take anything out of it. Some feedback was constructive though and we are reading more feedback everyday and try to implement what’s possible. We saw that EsysNeXt seems to be too complicated: We heard you and already are working on making car data available in less clicks. This feedback also comes into play for coding. We will make sure that it will be as self explaining as possible. There won’t be a need for a manual (hopefully).

The non-constructive feedback made us shut off registration as we have a clear path in mind and want to implement that distraction free. That does not mean that EsysNeXt, and especially the coding part, will be private forever. But it means, that we treat EsysNeXt now as a private Beta und work with the users, that are already registered, to iron out any non pleasant features or workflows and have a stable and awesome app as soon as coding is implement.

We have always been thinking of our former users first and were honest. We paid back any outstanding order as soon as we knew we couldn’t deliver EsysX anymore. One thing is for sure. Any existing user will get the compensated for

1. being a former customer and
2. for us not being able to deliver updates anymore up to the date of EsysNeXt coding release.

Yes, we are a business but we are also coders and first of all humans and we do not want to exploit the situation. We want to make sure that no one feels betrayed. Some people may think that you would have to pay again. But no, existing users won’t have to pay again for what they already have in their EsysX installation. Just to make it clear, anything thats additional to our old feature set, has to be paid, though. We try to keep anything as “on demand” as possible, so you only pay for what you need and when you need it.

We cannot tell more at the moment, but we will keep everyone updated on coding as soon as there is more info available.