Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Hardware Technology

Plug-and-Play for Automobile Embedded Systems 103

wskellenger writes "This article in the EE Times describes Autosar, a consortium of German automakers and suppliers that aims to standardize vehicle software infrastructure. In this way, vehicle software can be used in different ECUs, reducing complexity and development time for OEMs and suppliers."
This discussion has been archived. No new comments can be posted.

Plug-and-Play for Automobile Embedded Systems

Comments Filter:
  • Things have been going in this direction for quite awhile. The Corvette in 97 went to a serial communications protocol, talking to 14 different control units. It also had a throttle by wire system that eliminated a LOT of complexity in the traction control, cruse control and throttle applications. Active handling, a SIGNIFICANT feature, required a software change and two sensors.

    The next step is to get sensors to talk this protocol. Rather than having a dumb sensor that goes to a control unit that interprets the message, you have a temp. sensor that the manufacturer doesn't have to worry about. They just need to look for a temperature unit reporting water temp, or another unit reporting vehicle speed on the wire.

    Then the cruise control, the radio, the speedometer, etc all just have to listen for that packet that says 'wheel speed is 60 mph'.

    the Cool thing is, the vendor that makes the Vehicle Speed Sensor might do it today for $50. Next year it may be $42, the year after, they might redesign it to have zero moving parts (optical) and with custom asics, make it a $12 part. Will that translate to a cheaper vehicle for you? probably not...but it'll make your car last longer, and will be easier to troubleshoot.

    • NOT EVEN CLOSE, it will allow them to completely control the the replacement time of your entire car. This will make engineered obsolecence (sp?) the current corporate darling even more controllable. The vendor can sunset the support for your car because of software/firmware upgrade issues...Think of M$'s OS upgrade cycle and how much a durable goods manufacturer would like to be able to emulate that kind of re-buy re-supply cycle. Of course with the DMCA, you will be forbidden to try and revers engineer pa
    • Or on another level, could this mean that my cruise control/radio/whatever that is able to listen/speak this protocol in my truck can be easily pulled out and used in another vehicle? Modular components would be nice...
    • Things have been going in this direction for quite awhile. The Corvette in 97 went to a serial communications protocol, talking to 14 different control units.

      Meanwhile, the same technology was in German and Japanese cars at least 2-3 years before, depending upon the manufacturer. Who do you think GM got the idea from?

    • Not exactly. The sensor says "tempature 200." Is that oil tempature, engine water inlet tempature, or engine water outlet tempature? You specified water, but the same sensor [electronics?] may be used in different parts. Where was it installed needs to be indicated somehow.

      Some things can be infered if it is operating normally. Tempatures of 100 and 220 indicate inlet and outlet, respectivly (not sure if that is reasonable range, but you get the point). What if the sensor is broke though and is givi

    • To really understand the future of automation as it applies to cars, you really need to understand the driving factors behind it. Necessity is the mother of invention, and Economics are it's father. You need both to spawn the end product.

      To truely understand the process of moving from 'fully mechanical' to 'fully automated', just take a look at another industry that's much farther along that curve, and understand the reasons it is, and how it got where it is. Look at aviation, in particular, the large

    • Standards for communication protocols. A variety of components from different manufacturers, all interoperating because everyone follows the standards. "Embrace and extend" is fatal-- your components won't be chosen by the end user (in this case, the car manufacturers).

      This is a true driver of innovation (that word I always hear from one of our beloved software manufacturers). You know your product will compete on its merits, because any manufacturer (or, I suppose, car owner/tinkerer) can truly plug it in

    • We're already there. High-end vehicles since the early '90s all communicate using some sort of network protocol. Now on the lowest end vehicles you'll find multiplexing in use. For late model vehicles, CAN is becoming the most popular. (I work in vehicle development for a supplier of electronic brake systems such as ABS)

      Our ABS module reports vehicle speed (and actually four individual wheel speeds) that allow the 4WD system controller to do its job. Diconnect the ABS module and you also lose "automa

  • Can't wait for the first car worm.
    • I am going to write a worm that will roll down all of the car windows in the middle of winter when it hits -40.
      • Just make a worm that will do one of two things when it detects that the vehicle is in the left lane:

        1) speed up, or
        2) swerve to the right

        That will fix the biggest problem on our expressways.
    • Yeah, you could call the worm AutoSARS, har har.
  • The article says WindowsCE will be "taken into consideration" as part of the OS standard. I ask you do you really want a windows kernel controlling your anti-lock brakes?
  • The cartoon lied to me!

    Transformers aren't from another planet, they're from Germany.
  • Does this means that to fix a flat, we'll have to swap tires until we find the faulty one???
  • The ugly fact is all these computers have not made our cars more reliable. Im not against computers in cars but they need to have programs as simple as possible and these programs should be open source.

    If my computer crashes because of a bug I can replace it.

    If my car crashes because of a computer bug, me , someone I care about or someone who could sue me could be injured or killed.

    • The ugly fact is all these computers have not made our cars more reliable.

      Cars get far better gas milage and produce far fewer pollutants than they did before the introduction of electronics. I would argue that they are also more reliable. You can buy cars now that can be driven for 100,000 miles with only regular maintenance (oil, filters, etc). You don't even have to change the spark plugs.
    • Huh? A 1960's car would not drive for 55,000 miles with zero problems like my 2000 has. I think the engine electronics are at least part of that reliability. New International trucks use an ESC for everything from emergency light control to boom control. Due to many fewer physical modifications, reliability is expected to increase. (no more fire engine company splicing truck company wires to make the headlight blink) Or are you talking about safety. Air bags have quite a bit of electronics associated
      • You are correct. Im a classic car enthusiast and have had much dealing with older vehicles. Older vehicles (even when new) definatly require(d) more tuning/tweaking in order to remain reliable. However because of their simplicity they tend to suffer less from age and so break down less often. Modern designs are definatly less reliable after the 200,000km mark - but many people argue a vehicle should be scrapped by this time anyway.

        Its common to install fuel injection in older cars (cult cars) though, bec
    • So how many crashes can you attribute to closed-source embedded-system failures? You surely love the shorter stopping distances of ABS brakes. You doubtless like the fuel efficiency of advanced ignition timing that's possible now that engine control computers have replaced the old "points & condenser" systems of years ago.

      Ever wonder about the gibberish that your local import tuners (hot rodders with Hondas, Subaru's, etc) keep spewing about ECUs? They're reprogramming the air-fuel mixture at various p
      • Less software means less configurability
        Yeah, because pulling the block, boring it 30 over, putting in new headers, manifold, crank, cam, heads, pistons, rings, 4 bbl carbs (perhaps a predator tri-pak, and electronic ignition are oh so non-configurable!
        You haven't seen configurable unless you've seen a fully tricked out 30's street rod cruising town. Now that's a car.
        • Wow... I never thought of that. (insert sound of smacking forehead here)

          Oops! That's because most of those mods have either been done by the manufacturer of a modern car already (upgraded internals and better breathing), or the manufacturer's standard config (with things like fuel injection and distributorless ignition) is better. (Don't bother arguing that a 4 bbl carb is better than computer controlled port injection. Simpler, yes, but not better.)

          For example, take the F20C out of my car (Honda S2000),
    • If my computer crashes because of a bug I can replace it.

      If my car crashes because of a computer bug, me , someone I care about or someone who could sue me could be injured or killed.

      We replace a lot of modules, sensors and the like. The customer complaint is either "the check engine light came on" or "it's running/shifting a little rough." Your car will only crash from a faulty computer if you ignore the lights and let it go until the computer falls out of the car. Similarly, you'll only go off the

  • From their site:
    The standardization of automotive operating systems is not regarded as an AUTOSAR goal but existing standards and products such as OSEK, VxWorks, Windows CE for automotive and their derivatives will be taken into consideration and used in AUTOSAR.

    Adding in words like AUTOSAR interfaces, "AUTOSAR runtime environment (RTE)" and microprocessor abstraction layer, I'd say that they are taking a page out of Java's handbook.
  • This is interesting -- could this eventually do away with proprietary test computer equipment needed for each manufacturer? i.e. open it up into an environment where someone could extract this information via a some type of standard port to a laptop. Or would this lock it down further into more expensive (but standardized) equipment controlled by fewer providers? Anyone here have to deal with car problems & found you couldn't extract the details without an expensive "analysis" tool? (insert GM, Chrys
    • There are many aftermarket ECU manufacturers out there. A number of open source projects are getting close. It's only a matter of time before someone releases completely open hardware and software that can replace your car's ECU. Any modern RTOS is more than capable (QNX, for example).

      Unfortunately, the above is technically illegal in a lot of places because it lets you bypass emissions controls. Not where I live, though. :)
    • This won't even come close to solving this problem. All of the major manufacturers use different protocols which are not compatible, that is why there is no standard one-tool-fits all diagnosticl tool. When they came out with the OBD (on board diagnostic) standard, the only thing that was specified was a standard connector, each manufacturer developed their own implementation using whatever protocol they thought best. It's chaos for engine diagnostic software developers. There was a time not long ago whe
      • When Garymcg had the floor:

        each manufacturer developed their own implementation using whatever protocol they thought best.

        Yeah, and those dealers really want to standardize all the ODB diagnostics. Cause they don't want to charge you $100 just to run the diagnostic. GM only standardized because it was easier for them for two reasons, a)because all the cars were easier to manufacture if the only part that was different was the Chevy, Pontiac, or what have you emblem; and b) it was becoming a nightmare f

    • If you have access to a manual and a DVOM, you can see all the data you like without the expensive tools. I know this 'cause I was a Driveability Specialist (i.e. I diagnosed the electronic end of the automobile) before returning to school to become a 'Puter Engineer.
  • Software, schmoftware, I still want to be able to install a new radio without having to remove a series of plastic dashboard pieces larger than my torso. It's enough of a hassle that I end up paying people to do it for me. (Usually in beer, but the fact remains.)
  • by Animats ( 122034 ) on Friday October 10, 2003 @04:09PM (#7185625) Homepage
    There's SAE J1850. There's SAE J1939. There's CANbus. There's IEEE1394. There's FlexRAY. There's TTA. And they're all incompatible. Currently, TTA has Audi, Delphi Automotive Systems, Honeywell, PSA Peugeot-Citroen, TTTech and Volkswagen. FlexRay has BMW, Bosch Automotive Group, DaimlerChrysler, Ford, General Motors, Philips Semiconductors, and Texas Instruments. The US heavy-truck people have J1939. Some European truck makers use CANbus. J1850 is commonly used today for auxiliary functions in US passenger cars. None of this stuff interoperates.

    This new Autosar announcement is really a spec for an operating system. The companies pushing it don't want to say that, because that means taking on Microsoft. So they present this as a middleware layer. But it's really an operating system API that provides independence from the underlying OS. Think Netscape plug-ins.

    • This new Autosar announcement is really a spec for an operating system. The companies pushing it don't want to say that, because that means taking on Microsoft. So they present this as a middleware layer. But it's really an operating system API that provides independence from the underlying OS.

      This is important as Microsoft has expressed an interest in automotive control systems. In fact, I recently found out that the iDrive system in BMW 7 series automobiles is Windows CE based. (No wonder I hated t
    • Indeed there are a lot of different standards.
      J1939 is even subdivided into several different sub-protocols. The heavy vehicle stuff (also used by the military) is J1939/71. There are also different versions for factory automation and agricultural vehicles. What's really needed is a CAN type standard (either new or an extension of a current one) to allow standard parts to be hung on a car's bus and used by all manufacturers.

      I'm not sure if a fixed OS structure will be particuarly helpful. Different con
    • Does Microsoft really have much of a market in vehicle systems? I know they wanted to go there but in order to be there someone has to buy it and put it in their systems.

      I think legally automobile components have to be available for a decade. This means that MS has to allow licence sales ten years after replacing the product, and support the product through whatever fixes may be needed, not just support and sell for maybe five years as they does now.
    • My car has over 56 independent nodes running on three separate LAN protocols in a star topology centered on a multi-protocol gateway. Runs great, extremely reliable.
  • I was going to make a windows joke about this and then decided to actualy RTFA before posting and there it was, Windows CE! a few questions if automakers decide on windows... 1, will I have to agree to a Microsoft EULA in order to use the car? 2, will I need a separate Windows License for each Driver? 3, Will I be able to sell the car later or will I need to erase the operating system first ? 4, Will Windows DRM restrict what CDs I can play in the stereo? (will I even be able to install an aftermarket r
    • You know, I thought that was kind of a stupid, not as funny as intended kind of post until you got to the bit about the radio.

      I can just imagine MS putting code in that only permitted a DRM-compliant radio to work in a car - which would mean no home-burned compliations, legal or not, knowing the way DRM usually ends up 'functioning'.

      Anyway, I think that level of problem is far enough off that one need not be paranoid quite yet.

      • Yeah, I was debating as to if I should even post and I was trying to come up with at least one point that was not to stupid. All joking aside, this seems to be an application that is screaming for an open source or at least a BSD style solution. In the automotive business even pennies count so why would an automotive manufacturer even consider a solution which would have licensing issues ?
    • Buy an old Charger, Bird, Goat, Cuda, etc. No software to worry about. Just big, bad carbuerated engines belching smoke and fire... I mean, is there anything better than eight pistons beating in synchronization with your heart?
    • will I even be able to install an aftermarket radio?

      Hmm. depends. Some cars you can't now -- you have to keep your existing radio, or the car's computer will screw up. Like my Oldsmobile. Apparently there's some way of doing it that involves a re-location kit to mount it in the trunk, but that exceeds my attention span.
  • I don't want to have to hit CTRL, HORN, HAZZARDS every time I want to change the radio station.
  • ... The up side is, no body work, I'll just reboot it.

    The down side is, it will happen several times per week, and usually right when I most need to get somewhere...
  • The auto industry has been headed in this direction for a while. The biggest step was probably in 1996 when all (I believe) vehicles sold in the US were required to be compliant with the ODBII (On-Board Diagnostics II) standard interface. The result was that, to troubleshoot problems with the vehicle's engine and transmission, a person could pick up an OBDII code reader and pull the codes from a Ford, Chevy, Toyota, etc. Foreign or domestic -- it's the same standard.

    Granted, it a standard for pulling
  • Most problems I've had with my two cars have all been either sensor or controller issues. Seems the actual physical parts of today's cars work rather well, and don't ware out that fast. However the computer bits seem to be not as reliable.

    These parts are expensive because they are proprietary. Only a Ford controller can be fitted to a ford car. Doesn't matter who makes it, it has to be made specific for a given type of car no matter what. Standardizing would help bring these costs down a great deal.

    P
    • It's worse than that. Currently, only a Corvette Left Door Control Module can be used as a Corvette Left Door Control Module...

      What we need is a standardised spec with standardised connectors. That way you take your Napa Gold System controller, tell it it's a Corvette Left Door Control Module and go to town.

      (The aforementioned LDCM has a sensor to tell door state, relays to control door lock solenoid actuation, and relays to handle the power window. Concievably you'd buy a Napa Gold 4 port controller as i
    • Proprietary hardware and OS's in this day and age are redundant. No longer should this be seen as an advantage, because its not.

      There are some very powerful disincentives to introducing standardized (i.e. generic) hardware or software into any automobile. Start with the notion expressed in the EE Times article that software from one manufacturer would run on another's hardware. Today the auto industry treats software as if it were free, and pays only for metal boxes with wires coming out of them. The Euro

  • The Ottawa Citizen newspaper just had a profile on QNX as part of their semi-annual high-tech review. It goes into quite a bit of detail about QNX's recent move into the automotive space. Ottawa Citizen Link: QNX operating system revs up for the road [canada.com]
  • Bug or Lemon (Score:3, Interesting)

    by OYAHHH ( 322809 ) on Friday October 10, 2003 @04:36PM (#7185739)
    So,

    At what point does all the computer bugs in your car create a point where you can legitimately invoke the lemon law provisions?

    On a side note I started trailing a lady in a brand new BMW 7 series a couple of days ago. The car's emergency flashers were on and at the leisurely pace she was taking things I knew she wasn't aware of it.

    So I pulled alongside at a redlight, fortunately she had her drivers side window down, so I shouted to her that her emergency flashers were on.

    She looked really surprised and muttered something to the effect of "Oh really". Not a doubting oh really, but a surprised oh really.

    Apparently there was no indicator inside the car telling her what was happening with her lights.

    If I'm not mistaken the BMW 7 series has a Windows CE O/S? I've heard the 5 series does.

    I know I'd be incredibly irritated to spend the kind of money she had in that BMW only to find it riddled with computer bugs.

    Lastly, isn't it the law in the US that car makers have to "support" the vehicles they sell for 8 years?

    Will MS still be willing to issue a BMW patch 8 years from now? They've certainly seemed to be trying to reduce the amount of time they support a particular version of their O/Ses.
  • What I would like is the ability to run a cable (USB/ serial/ firewire/ ethernet/ whatever) out to my car and fire up some open source diagnostic software on my computer to get some hints at what's wrong *before* I haul it in to the service center.
    • Then get a Volkswagon. You can run hook your laptop up to the computer in a VW (or Audi, Seat, or Skoda) and get all sorts of nifty information (http://www.ross-tech.com/vag-com/), and even adjust the performance and emissions characteristics of the car. The open-source part is the trick, though. Aside from the expensive connector, you have to pay another couple hundred bucks for the software. I'd be very happy if somebody wrote some freeware similar to VAG-COM.
    • I'm pretty sure you can already do this.

      The diagnostic interface to all cars that are sold in the USA *is* standardized. Look under the dash somewhere close to the steering wheel and you should see a socket (probably covered with a snap-shut cover). This must conform to the 'OBDII' standard.

      You can buy the interface pack to hang a laptop or PDA onto the car:

      eg: http://www.elmelectronics.com/

      There are also circuit diagrams out there to let you build your own if you want to (they interface into the se
  • Vehicle software (Score:2, Interesting)

    I believe this will have a positive impact on the cost and maintenance of my future car. Lowering the cost from the current $100 to a future of $25 for one sensor/device may not have much of an effect, but for 100 different sensors it should have a very positive effect. And with the many manufacturere producing standards compliant sensors/devices the reliability of our vehicles is also bound to increase. I jut have a few questions here:

    1. How will the DMCA affect this? Will we still be able to work on our
    • What about the black boxes [ieee.org] that are now standard in cars?

      According to the link you posted, these aren't standard... the standard for them is being developed. At least, it was as of April 2002, and it seems unlikely that in less than a year it's gone from concept to standard equipment.

      However, standardization of car electronics interface would probably make the project you've pointed out quite a bit easier.
  • That is a question that must be answered. How reliable would the new standard enforce. Issues regarding noise on the bus, or component failure causing the ECU to go nuts, etc.


    It is a nice idea to have plug and play components and are able to access the control system for tweeking, diagnostics, etc. But, you also have to consider how much control should a car owner/user be permitted to do.

    • I agree - and it's not just electrical noise (which is a big problem with all of those sparks going off at a few tens of kilohertz - and the starter motor) - but there are also thermal issues (it gets pretty hot under the hood) and vibration too.

      It's not going to be easy to physically manufacture a workable/reliable ECU.

      Then you can bet there are going to be liability issues in car wrecks.

      It really doesn't bear thinking about - yet it's something I think NEEDS to be thought about. OpenSource software un
  • While you're at it, please standardize audio components. Make all audio decks the same size (DIN would do nicely), have standardized connections (so I don't have to use a harness).
    Standardize the on-the-wheel audio control interface so I can use it to do simple things like control volume, skip/search track/station.

    If someone could do this, we would all save hundreds by not getting the overpriced audio options the car dealer has. Whoops, doesn't sound like it'll happen anytime soon.

  • by sbaker ( 47485 ) on Friday October 10, 2003 @05:24PM (#7185980) Homepage
    The new BMW MINI Cooper has an ECU built by Siemens and programmed by yet a third company. BMW claim that they don't even have a copy of the source code for their own car! The same ECU is used in a variety of engines. So in order to have the code optimised for a particular car, the software "learns" - over several tankfuls of gas - how best to drive the car. Since cars change over time, it continually re-learns. If you add a new air-filter for example - the effects of doing it only gradually appear - over about three tankfuls - as the ECU learns to adjust the fuel/air mixture again.

    This has consequences. Firstly, when you buy a new MINI Cooper, you get really poor gas milage for the first few tanks of gas - but gradually (as the ECU learns), it gets better.

    So far, so good.

    But the MINI has a problem (known as the 'stumble' amongst owners) - it's a software bug that appeared in 2003 model-year cars - older cars don't have it unless they upgrade to the 3.3.x version of the ECU software for some reason.

    Under the special combinations of high air temperatures (and perhaps only in low humidity) in the summer in the southern USA - and with 'Reformulated Gasoline' that we get here in Texas and in Florida - the car sometimes stalls out at dangerous times. (eg You pull out into traffic - and the car stalls halfway across the road).

    The stumble was VERY hard to diagnose - both because BMW couldn't reproduce the problem - it took a lot of MINI enthusiasts across the US to finally figure it out.

    We (within the owner's community) decided that this couldn't possibly be temperature related - because the car would still stumble in the cool of early morning. We decided it couldn't be reformulated gas because we could drive to Oklahoma - buy a tankful of "the good stuff" - and still experience the stumble.
    During a heatwave in Washington (who also have reformulated gas) - there were no reports of 'stumbles'.

    These were cases where diagnosis was made almost impossible because the ECU had *learned* to stumble - and needed either cool temps or better gas for THREE TANKFULS in order to recover from it. People who experienced a short heatwave - or who bought only one or two tankfuls of reformulated gas didn't see the problem.

    In consequence, it's taken over a year to convince BMW that there really is a problem and to find out what it is. However, BMW themselves can't fix it. They have to work through Siemens to get to the third company who programed the ECU so it could be fixed - and those guys didn't want to just fix it "the easy way" because it would have the potential to screw up performance in other kinds of car that use the same ECU software.

    We are promised a fix for the stumbles - sometime in December.

    This is all VERY yukky and unsatisfactory.

    The thought of trying to write OpenSource ECU software came to mind - and there are some projects out there to do just that. This ECU has reloadable software - using a serial port connection that appears just under the steering wheel (used for emissions control stuff too). You can buy a cable to adapt the car's serial port to that of your laptop or PDA - and there is even software to let you read out and reset the engine management error codes in the comfort of your own driveway.

    Armed with a laptop, your car dealership can upload new software into your car in about 20 minutes.

    However, attempts to do this ourselves resulted in a fascinating inside into what the world of Palladium/DRM. When you tell the MINI "Please accept a new software load" - it sends you back a 16 bit random number. You are supposed to execute some predefined math operations on that number and send back the result as another 16 bit number. If you get the answer wrong, the car completely shuts down for 3 HOURS! You can't even start it under those circumstances - let alone try again with the software download. Obviously, the math operations you have to evaluate to solve this challenge/response scheme are secret.

    So - welcome to the world of the future. For some of us it's already here!
    • Thank heavens I have a real mini cooper. (1973)
    • I haven't had the stumble or "yo-yo" as it's also known in my September 02 build MINI Cooper S ('03 model year). Could be that the right conditions just haven't happened for me. The Raleigh area doesn't use the reformulated (i.e. crappy) gasoline, although we do get high temps in the summer (95F and up).

      I am selling my car [autotrader.com], however. The MINI is a fantastic car, but I want an IS-300 instead.

      Chip H.
      • I also have an 02-build/03-model-year MINI - and I don't have the problem.

        So long as you don't get the ECU software upgraded to the 3.2, 3.3, 3.4 or 3.5 ECU software - you should be fine. The 3.6 version is supposed to have the fix - and versions prior to 3.2 don't seem to exhibit the problem.

        Without reformulated gas, I doubt you'd ever see the problem - and even if you happened to visit a place that has it and bought just one tankful, I don't think that's enough to throw the ECU's algorithms off enough
  • I think a well-defined time-tested industry standard protocol like RS485 should be considered. RS-485 is a serial protocol that uses balanced signaling (good for noisy enviroments) and can handle multiple devices on the same wire.
  • What happens when the MSFT OS detects that your steering wheel, breaks, and airbag have all been ejected, when you fully know they are still plugged in!

  • I prefer to use Homsar [homestarrunner.com], the captain of the gravy train. It's a song form the sixties.
  • I have somewhere in my archives an article about a woman having to pay her Volvo dealer close to $100 per download for software downloads as part of the procedure to replace the electronic keys on her car after she misplaced the keys. Not only didn't the ~$500 set of keys and resetting of the computer in her car not work very well, but her old keys, which were supposed to be invalidated by the downloaded codes, worked perfectly when she found them. If more repairs are done electronically, and the software
    • I would assume that when the day comes that you can upgrade the OS on your car's ECU in your driveway, that some of the paperwork you sign for the warranty on your new car is going to get a lot more intricate. I think it would be completely reasonable to have a separate shop-rate for computer-related issues, if it were easy enough for the owner/end-user to change settings.

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...